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ABSTRACT 

The  premise  of  this  thesis  is  that  many  software 
application  systems  oerform  similar  functions  on  a  data 
object  and  contain  a  significant  operational  intersection. 
An  integrated  Apoiication  Software  System  (iass)  integrates 
the  caoaoilities  of  the  applications  into  one  system.  The 
purpose  of  this  thesis  is  to  evaluate  the  utility  of  the 
relational  database  model  to  conceptually  integrate  the  text 
processing,  relational  database  management,  form  generating, 
electronic  mail,  and  electronic  modeling  aDOlications . 

The  conclusion  of  tnis  study  is  that  the  relational 
database  model  can  conceptually  support  the  data 
representation  and  manipulation  reguirements  of  Qach 
application  considered.  Furthermore,  the  integrated  system 
has  potential  capapilities  that  are  not  available  in  the 
non-integrated  set  of  applications. 
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I.   INTRODUCTION 

A.   APPLICATION  SOFTWARE  PROBLEM 

The  utilization  of  computers  in  many  areas,  such  as 
personal  computing  or  office  and  manuf acturing  automation, 
is  rapidly  expanding.  No  longer  is  their  use  being 
relegated  to  support  personnel,  but  is  spreading  into  the 
ranks  of  lower  and  middle  level  management.  The  majority  of 
such  users  are  non-computer  professionals  who  are  coming  to 
depend  on  the  computer  to  provide  support  to  accomolisn 
their  primary  responsibilities. 

Over  the  past  years,  numerous  software  packaaes  have 
been  made  available  to  support  a  broad  spectrum  of  users  in 
varying  environments.  Capabilities  such  as  word  orocessing, 
database  management,  modeling,  form  generation,  and 
electronic  mail  have  become  essential.  The  ourpose  of 
introducing  the  computer  into  an  organization  is  to  increase 
effectiveness  and  efficiency.  While  the  performance  of  eacn 
support  package  is  individually  satisfactory,  the  manner  in 
which  they  are  presented  to  the  user  as  a  group  is  not.  As 
illustrated  in  Figure  1.1,  each  support  system  is  typically 
disjoint  from  all  others,  and  the  user  is  presented  with 
different  models,  command  vocabularies,  and  operating 
instructions.     This    non-lntearated    combination    of 


application  software   requires  a  special  effort  on  the  part 

of  the  user  to  learn  a  new  system  and  remember  it  along  with 

the   other  systems  that  are  used.   For  instance,  one  simple 

task  can  be  invoked  in  a  different  way  in  each  system. 


Figure  1.1  -  Disjoint  SUDport  systems. 


B.   THE  IASS  OBJECTIVES 

What  is  needed  to  increase  productivity  is  an  Integrated 
system  that  combines  the  capabilities  of  the  applications 
and  presents  tne  user  with  a  single,  yet  easy,  conceDtual 
data  model  and  vocabulary  set.  It  is  such  a  system  tnat  is 
called  an  Integrated  ApDlication  Software  System  (IASS).  The 
oojectives  of  such  a  system  are: 

CI)  Ensure  a  high  degree  of  user  friendliness  and 
emphasize  simplicity. 

(2)  Minimize  the  Initial  and  acquired  user  skill  level 
necessary  to  use  the  system. 

(3)  Minimize  the  learninq  time  reauired  to  use  the 
system. 


(4)  Present  a  logical  distinction  between  each  of  the 
IASS's  capabilities,  but  minimize  explicit  navigation 
between  them. 

(5)  Realize  the  largest  functional  intersection  of  the 
capabilities  of  each  included  application, 

(6)  Develop  a  minimum  set  of  primitive  commands. 

(7)  Minimize  the  dependence  on  programming  in  order  to 
use  the  system. 

(8)  Embody  the  notion  of  software  adaptivity  whereby 
the  user  can  learn  a  new  application  by  learning  only  a 
small  increment  of  new  apolication  specific  commands  and 
functions. 

(9)  Embody  the  notion  of  software  reusability.  New 
applications  can  oe  implemented  by  adding  a  small  increment 
of  functions  and  commands  which  can  be  expressed  in  terms  of 
existing  IASS  operations. 

while  the  IASS  cannot  be  expected  to  completely 
integrate  tne  features  of  each  support  pacKage,  it  can 
strive  to  maximize  tne  intersection  between  them.  Figure  1.2 
shows   a   simple   illustration  of  an  IASS  in  a  Venn  Diagram. 


1 

[ 

2 

^ 

l_ 

[ASS 

3 

4 

Figure  1.2  -  IASS  Intersection. 
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The  purpose  of  this  thesis. is  to  determine   the   utility   of 
the  relational  database  model  as  the  Kernel  of  the  IASS. 

C,   IASS  APPLICATIONS 

Five  common  software  applications  were  selected  to  be 
integrated; 

CI)  Text  Processor 

(2)  Relational  Database  Management  System 

(3)  electronic  Spread  Sheet 

(4)  Forms  Generator 
C5)  Electronic  Mail 

As  a  non-integrated  collection  of  application  software, 
each  is  implemented  to  accomDlish  a  predefined  set  of 
operations  on  a  specific  file  type.  Data  in  a  file  is  not 
directly  sharable  between  apDlications  and  neither  are  the 
commands  to  manipulate  the  data.  Command  vocabularies  are 
usually  "baroaue"  in  that  most  of  the  operators  are  intended 
to  exist  as  a  matter  of  convenience  to  tne  user.  However, 
too  often  it  is  a  very  small  percentage  of  the  overall 
vocabulary  that  is  used  most  of  the  time.  Users  usually 
learn  a  subset  of  the  vocabulary  necessary  to  accomplish  the 
essential  functions  of  tne  application,  and  disregard  the 
rest.  It  is  the  intersection  of  functions  and  vocabularies 
that  the  IASS  suosumes  and  maices  the  common  system  for  all 
included  applications. 
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Commercially  available  software  application  packages 
were  reviewed  to  determine  the  nature  of  the  logical  file 
types  and  tne  essential  functions.  A  detailed  descriDtion 
of  each  of  the  application  packages  is  included  in 
Appendices  A  through  I, 
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II.   IASS  DATA  OBJECT 

A,   THE  TABLE 

The  logical  file  of  any  application  system  contains  data 
which  is  used  by  a  specific  set  of  application  programs. 
The  Key  to  achieving  an  Integratea  Application  Software 
System  (IASS)  which  can  support  each  logical  file  type  is  to 
map  each  Into  one  data  object.  The  data  object  chosen  for 
the  IASS  is  the  table  since  it  is  a  natural  method  of 
organizing  data  and  is  an  easily  understood  object.  Each 
column  in  the  table  represents  one  attribute  of  the  file  and 
each  ro*  represents  an  unique  occurrence.  The  taoles 
include  columns  which  represent  Key  values  to  uniquely 
identify  eacn  row.  Any  datum  in  a  table  can  be  accessed  by 
specifying  the  name  of  the  table,  the  value  of  the  Key,  and 
the  name  of  the  attribute  containing  tne  datum.  In  this 
thesis,  rows  win  win  also  be  referreo  to  as  tuples  or 
lines  and  columns  as  attributes  or  fields.  A  complete 
description  of  the  taole  is  given  in  Martin  CRef.  13, 

This  chapter  descrioes  tne  preliminary  cesign  of  a  set 
of  tables  *hicn  can  support  the  data  requirements  of  the 
IASS  applications. 


13 


6.   IASS  TABLES 

In  the  IASS  each  application  is  a  logical  database 
consisting  of  a  set  of  tables.  There  are  three  general 
classes  of  tables,  data  table,  application  directory,  and 
data  table  schema.  The  data  table  represents  the  logical 
file  of  an  application.  The  data  tables  are  typed  according 
to  trieir  primary  use  as,  text,  form  text,  database,  sDread 
sneet,  and  mail.  Data  table  typing  is  done  only  to 
logically  organize  data  taoles  which  are  used  primarily  by 
the  same  application  programs.  The  IASS  does  not  support 
strong  data  table  typing.  Being  able  to  combine  taoles  of 
different  types  is  an  important  feature  of  the  IASS, 

The  application  directory  table  contains  descriptive  and 
definitional  data  aoout  Che  data  tables  in  an  application  or 
logical  dataoase.  Each  row  in  tne  application  directory 
table  describes  one  data  table  and  has  a  standard  schema, 
Figure  2.1.  ID  is  the  primary  Key  value  of  the  apciication 
directory  table.  NAME  is  the  unique  name  of  the  data  table, 
COLUMNS  is  a  list  of  column  names  In  the  data  table.  This 
list  implicitly  defines  tne  schema  of  the  data  taole. 
ACCESS  CONTROL  defines  the  access  privileges  of  various 
classes  of  system  users  to  the  taole,  including  read  and 
write  access  and  privileges  to  modify  tne  data  taole  schema. 
This  data  item  also  contains  information  concerning  wnich 
operations  are  allowed  on  the  data  taole.  For  instance,  it 
may  be  decided  that  one  dataoase  data  taole  cannot  be  joined 


14 


with  a  mail  data  table.  TABLE  POINTER  points  to  the  data 
table.  DESCRIPTION  is  a  literal  description  of  the  table. 
VIRTUAL  indicates  whether  the  data  table  is  composed  from 
other  IASS  data  taoles.  CONDITION  indicates  how  a  virtual 
table  is  composed.  For  example,  if  the  virtual  data  table 
was  formed  by  a  join,  that  data  would  be  stored  in  the 
CONDITION  column  of  the  application  directory.  GLOBAL 
contains  all  the  recurring  information  which  is  applicaoie 
to  a  data  table  as  a  whole,  such  as  formatting,  display  mode 
(e.g.  page  or  taole),-  access  patns,  etc.  For  each 
application,  the  schema  of  the  application  directory  table 
can  be  auomented  as  required. 


NAME 


COLUMN'S 


ACCESS 
CONTROL 


TABLE 
POINTER 


VIRTUAL 


CONDITION 


GLOBAL 


DES- 
CRIPTION 


Figure  2.1  -  Application  Directory  Table  Schema 


The  data  table  schema  taole  contains   a   row   for   each 

column   in   the   data   tables.  The  schema  of  the  data  table 

schema  table  Figure  2.2,  is  the  same   in   each   application. 

ID   is   the   primary  Key  of  the  taole.   Each  column  in  the  a 

data  table  has  an. unique  NAME.  TYPE  and  WIDTH  descrioe   the 
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data   type   associated  with  the  column  and  the  maximum  width 
of  the  data  entry. 


ID 

NAME 

TYPE 

WIDTH 

SYNONYM 

TABLE 

ACCESS 
CONTROL 

Figure  2.2  -  Data  Table  Schema  Table 


Data  typing  supports  the  data  integrity  function  of  the 
underlying  system.  SYNONYM  is  the  list  of  names  dv  which 
the  column  could  be  referred.  This  information  is  used  to 
determine  relationships  that  exist  with  otner  data  tables, 
possibly  of  a  different  type  or  allows  tne  same  column  to  be 
referred  to  Dy  many  different  names  depending  on  the  context 
of  its  use.  For  example,  in  a  personnel  data  table,  the 
column  name  may  be  PNAME.  This  column  could  be  referred  to 
as  PERSNAME,  name,  PERSON,  etc.  This  column  must  oe  used 
with  caution.  Its  data  may  inadvertently  change  the  access 
privileges  of  a  user  to  a  data  item.  TABLE  is  the  data 
tables  the  column  occurs  in.  A  guery  of  the  data  table 
schema  table  can  be  done  to  determine  the  names  of  the 
tables  the  column  is  In  to  avoid  searching  througn  an  entire 
application  directory.  ACCESS  CONTROL  defines  the 
privileges  associated  with  eacn  column  tor  a  class  of  system 
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users  Including  read  and   write   access   and   privileges   to 
modify  tfte  column  definition. 

Figure  2,3   shows  the  relationships  between   the   tables 
that  exist  in  each  application. 


Application  Directory 


ID 


NA.ME 


COLUMNS 


ACCESS 
CONTROL 


TABLE 
POINTER 


VIRTUAL 


1 


CONDITION 


GLOBAL 


DES- 
CRIPTION 


Data  Table  Schema 


DATA 
TABLE 


ID   I 

^AME 

TYPE 

WIDTH 

SYNONYM 

TABLE 

ACCESS 
CONTROL 

Figure  2,3  -  IASS  Table  Relationsnips 


This  figure  indicates  that  each  row  in  the  application 
directory  tacie  is  connected  to  a  set  of  rows  in  the  data 
table  schema  table  and  a  data  table.  The  dotted  line  shows 
a  cross  reference  from  a  data  table  schema  table  row  to  a 
directory  table  row. 
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1 •   Text  Processor  Tables 

a.   Text  Directory  Table 

The  text  directory  table  contains  a  row  for  each 
text  data  taole,  The  directory,  Figure  2.4,  has  the 
standard  application  directory  schema.  Since  the  text  data 
taoles  can  be  output  to  a  visual  medium,  each  data  table  has 
a  global  print  format.  This  data  is  stored  in  the  GLOBAL 
columns  or,  if  necessary,  in  a  table  accessed  via  tne  data 
in  the  GLOBAL  columns,  and  contains  the  page  length,  right 
and  left  margin,  top  and  bottom  margin,  number  of  lines  Der 
page,  page  neader,  page  footer,  tab  spacing,  and  line 
spacing. 


ID 


NAME 


COLUMNS 


ACCESS 
CONTROL 


TABLE 
POINTER 


VIRTUAL 


CONDITION 


GLOBAL 


DES- 
CRIPTION 


Figure  2.4  -  Text  Directory  Taole  Schema 


b.   Text  Data  Table  Scnema  Table 

The  text  data  table  schema  table,  Figure  2,5, 
contains  the  predefined  column  set,  ID  and  TEXT  LINE.  The 
ID  is  the  primary  Key  of  the  text  data  table.  TEXT  LINE 
descriPes   the   TEXT  LINE  column  in  tne  text  data  table.   As 
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Figure  2.5  shows,  the  TEXT  LINE  can  be  aliased  with  the  FORM 
LINE  column  in  a  form  text  data  table  or  the  BODY  column  in 
a  mail  data  table. 


ID   NAME   TYPE   WIDTH    SYNONYM   TABLE 


ACCESS 

CONTROL 


1 

ID 

IN- 
TEGER 

NONE 

ALL 

read:  all 
write:  DBA 
modify:  DBA 

2 

TEXT 

LINE- 

CHAR 

FORM 

LINE, 

SODY 

ALL 

read:  all 
write:  all 

modify:  DBA 

Fiaure  2.5  -  Text  Data  Table  Schema  Table 


c.   Text  Data  Table 

The  text  data  table,  Figure  2.6,  is  described 
by  the  COLUMNS  and  DESCRIPTION  columns  in  tne  text  directory 
table.  It  contains  data  used  to  prepare  a  printed  document 
or  a  computer  program.  The  rows  in  a  text  table  are  sorted 
on  the  ID  column.  Each  row  has  an  unigue  ID  number  *nich 
corresponds  to  the  line  number  in  the  display.  Although  the 
user  can  refer  to  an  ID  numoer,  an  ID  number  cannot  oe 
directly  modified.  The  data  in  a  TEXT  LINE  is  unformatted. 
In  a  single  line  of  text,  there  are  two  Kinds  of  data  that 
are  recoanizea,  the  character  string  to  be  printed  and 
special  comomations   of   characters   to   oe   executed.   The 
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executable  characters  are  specific  to  a  text  processor 
application  program  (e.g.  text  formatter  or  compiler). 
Figure  2,6  shows  the  two  <inds  of  data.  Rows  1  and  2 
contain  literal  character  strings  to  oe  printed.  Row  n 
contains  a  formatting  command  (page-break) , 


ID 


TEXT  LINE 


now  is  the  time 


2   for  ali  good  men  to 
n  I  .pa 

Figure  2.6  -  Text  Data  Table 


2,   Dataoase  Tables 

a.   Database  Directory  Table 

The  database  directory  table  contains  a  row  for 
each  database  data  taole.  The  dataoase  directory  table, 
Figure  2.7,  nas  the  standard  application  directory  schema. 
The  GLOBAL  column  contains  data  descrioing  the  display  mode 
or  printed  format. 


ID 


NAME 


COLUMNS 


ACCESS 
CONTROL 


TABLE 
POINTER 


VIRTUAL 


CONDITION 


GLOPAL 


DES- 
CRIPTION 


Figure  2.7  -  Database  Directory  Table  Schema 
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b.   Database  Data  Table  Schema  Table 

The  database  data  taDle  schema  table,  Figure 
2.8,  Initially  contains  an  entry  only  for  the  ID  column. 
The  ID  is  a  Key  in  the  database  data  table.  As  dataoase 
data  tables  are  defined,  entries  to  the  database  data  table 
schema  table  will  have  to  be  made. 


ID   NAME   TYPE    WIDTH   SYNONYM    TABLE 


ACCESS 
CONTROL 


1 

ID 

INTEGER 

NONE 

ALL 

read:  all 

write:  DBA 
modify:  DBA 

Figure  2.8  -  Database  Data  Table  schema  Table 


c.   Database  Data  Table 

Each  database  data  table,  Fiaure  2.9,  represents 
one  entity,  and  is  descrioed  by  the  COLUMNS  and  DESCRIPTION 
column  in  the  database  directory  taole.  The  data  in  a 
aataoase  data  table  is  formatted.  Each  row  is  an  unique 
occurrence  of  the  entity.  Tne  columns  of  tne  database  data 
table  are  the  attributes  of  the  entity.  ID  contains  the 
display  order  of  a  row.  This  ordering  does  not  imply  tnat 
there  Is  a  canonical  ordering  of  the  entity.  The  ID  can  De 
referred  to  but  cannot  be  directly  modified  by  the  user. 
The  other  columns  of  the  database  data  table  are  not 
predefined.   The  database  data  table  can  De  directly   viewed 
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at  the  screen  by  the  user  or  printed,  but  may  be  reformatted 
based  on  the  data  in  the  GLOBAL  column  if  necessary. 


ID    ATTR-1    ATTR-2 


ATTR-n 


1 

2 

m                   « 
|                      1 

>                                   m                                  m 
1                                     1 

m                                       m 
1                                     J 

Figure  2.9  -  Database  Data  Table 


3,   Form   Generator  Tables 

a.   Form  Text  Directory  Table 

The  form  text  directory  table  has  the  standard 
applications  directory  schema,  Fiaure  2,10.  Because  the 
form  is  intended  to  be  Drinted,  each  for*  contains  a  orint 
format  which  is  defined  by  the  data  aoareqate  named  GLOBAL. 
This  data  aoareoate  is  the  same  as  that  contained  in  the 
text  directory  table  previously  described. 


ID 


NAME 


COLUMNS 


ACCESS 
CONTROL 


TABLE 
POINTER 


VIRTUAL 


CONDTTIHN 


GLOBAL 


DES- 

CRIPTION 


Fiaure  2.10  -  Form  Text  Directory  Table  Schema 


22 


b.   Form  Text  Data  Table  Schema  Table 

The  form  text  data  table  schema  table,  Figure 
2« 1 1  contains  the  predefined  column  set  ID  and  FORM  LINE. 
The  ID  is  the  primary  Key  of  the  form  text  data  table.  FORM 
LINE  describes  the  FORM  LINE  column  in  the  form  text  data 
table.  Fiaure  2.11  shows  that  the  FORM  LINE  column  can  be 
aliased  with  the  TEXT  LINE  column  in  a  text  data  taole  or 
the  BODY  column  in  mail  data  table. 


ID   NAME  TYPE    WIDTH   SYNONYM    TABLE 


ACCESS 

CONTROL 


1 

ID 

IN- 
TEGER 

NONE 

ALL 

read:  all 
write:  DBA 
modify:  DBA 

2 

FORM 
LINE 

CHAR 

TEXT 

LINE, 
BODY 

ALL 

reaa:  all 
write:  all 
modify:  DBA 

Figure  2,11  -  Form  Text  Data  Taole  Scnema  Table 

c.   Form  Text  Data  Table 

A  form  is  a  repetitive  document  with  blanXs  to 
be  filled  in.  A  form  can  oe  represented  as  a  collection  of 
rows  contained  in  a  table,  as  shown  In  Figure  2.12,  and  is 
descrioed  oy  tne  COLUMNS  and  DESCRIPTION  columns  in  the  form 
text  directory  taole. 
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ID 


FORM  LINE 


1 

{NAME) 

4 

<ADPR£SS> 

3 

4 

Dear  (3. RELATION} 

5 

POftHl.TXT 

Figure  2.12  -  Form  Text  Table 


Each  row  of  the  table  is  sorted  on  the  ID  and  corresponds  to 
the  same  row  in  the  form.  Althougn  the  user  can  reference 
an  ID  number,  it  cannot  be  directly  modified.  The  FORM 
LINE  column,  contains  unformatted  data.  In  addition  to 
literal  character  strings  which  are  printed,  including 
horizontal  and  vertical  lines,  it  contains  a  special  set  of 
executable  data.  A  special  character  comoination  Indicates 
whether  the  blanks  in  the  form  are  to  filled  in  by  the  user 
and  stored  in  a  table,  or  wnether  tne  blanks  are  to  be 
filled  in  from  a  taole,  This  special  set  of  data  must  oe 
Known  by  the  user  as  it  is  merely  inserted  as  a  combination 
of  characters  into  the  FORM  LINE  column.  The  view  of  tne 
form  at  design  and  modification  time  is  exactly  that  of  the 
form  data  table  although  it  may  be  reformatted  if  necessary. 
Figure  2.12  contains  an  example  of  the  data  in 
the  form  text  data  table.  The  data  in  tne  first  FORM  LINE 
indicates  that  the  printed  value  for  the  first   row   in   the 
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printed  form  is  to  be  retrieved  from  the  NAME  column  of  the 
selected  row  of  the  associated  database  data  table.  Tne 
data  in  the  fourth  FORM  LINE  indicates  that  the  printed-  form 
is  to  contain  the  literal  string  'Dear'  followed  by  tne 
value  from  the  RELATION  column  of  table  B  of  the  associated 
database  data  table.  The  information  in  row  4  also 
indicates  that  the  associated  taole  is  a  join  of  two  taoles 
each  containing  a  column  named  RELATION.  Row  5  indicates 
that  the  body  of  tne  form  is  a  text  data  table  named  FOftMl, 

A  form  text  data  table  is  similar  to  a  text 
table.  They  differ  only  in  their  data  content  and  the  way 
they  ^re  used.  The  data  in  ere  form  text  data  table  can  be 
variables  whose  values  are  determined  at  print  time.  The 
variables  in  a  form  do  not  h^ve  to  be  bound  to  a  named  data 
table  or  specific  row  in  a  data  table  and  therefore  can  be 
re-used  in  tne  same  or  in  many  different  aoolications . 
4.  Electronic  Mail  Tables 
a.   Mail  Directory  Table 


ID 


NAME 


COLUMNS 


ACCESS 
CONTROL 


TABLE 
POINTER 


VIRTUAL 


CONDITION 


GLOBAL 


DES- 
CRIPTION 


Figure  2.13  -  Mall  Directory  Table  Schema 
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The  mail  directory  table  contains  a  row  for  each 
mail  table.  The  standard  application  directory  schema  does 
not  have  to  be  modified  for  the  mail  application,  Figure 
2,13.  The  GLOBAL  data  items  contain  the  data  to  determine 
ownersniD  of  the  mail  data  table  and  any  other  aoplicahie 
information. 

o.   Mail  Data  Table  Schema  Table 


ID    NAME   TYPE  WIDTH  SYNONYM    TABLE 


ACCESS* 

CONTROL 


1 

ID 

INTE 
-GER 

N'  P  H  E 

ALL 

read:  all 
write:  DBA 
modify:  DBA 

2 

FPTM 

CHAR 

- 

NOME 

ALL 

r°ad:  all 
write:  all 
modify:  DBA 

3 

TO 

CHAR 

NONE 

ALL 

read:  all 
write:  all 
modify:  DBA 

4 

COPY  TO 

CHAR 

NONE 

ALL 

read:  all 
write:  all 
modify:  DBA 

s 

DATE 

CHAR 

NONE 

ALL 

read:  all 
write:  all 
modify:  DBA 

ft 

SUBJ 

CHAP 

SUB- 
JECT 

ALL 

read:  all 
write:  all 
modify:  DBA 

7 

30DY 

CHAR 

TEXT  LINE, 

FORM  LINE 

ALL 

read:  all 
write:  all 
modify:  DBA 

Figure  2.14  -  Mail  Data  Table  Schema  Table 
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The  mail  data  table  schema  table,  Flcure  2.14, 
contains  the  system  defined  columns  of  a  message.  The  ID  is 
the  primary  Key  of  each  mail  table.  The  other  columns 
contain  the  data  to  denote  the  originator,  reciDients, 
subject  and  the  body  of  the  messaoe.  Figure  2.14  shows  that 
the  BODY  can  be  synonymous  with  the  TEXT  LINE  of  a  text  data 
table  or  FGRM  line  of  a  form  text  data  table 
c.   Mail  Data  Table 


ID  FROM    TO 


COPY  TO  DATE  SU3J  BODY 


I 

ME 

YOU 

THEM 

1/1 

MESSAGE 

2 

you 

ME 

THEM 

1/2 

^SG.TXT 

m            * 

f                                 m 

»                    « 

*                 ■ 

*         « 

•         m 

0                                                                                                                                                             •* 

n 

Figure  2.15  -  Mail  Data  Table 


Electronic  mail  is  a  utility  which  facilitates 
the  excnance  of  textual  messages  between  system  users.  A 
mail  file  contains  a  set  of  messages.  The  message  consists 
of  data  items  which  are  read  by  the  recipients.  The  mail 
table,  Figure  2.15,  is  described  by  the  COLUMNS  and 
DESCRIPTION  columns  in  the  mail  directory  table.  Each  row 
in  the  table   correscon<is   to   one   message.    Each      message 
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contains  a  header  which  is  comprised  of  the  FROM,  TO,  COPY 
TO,  DATE,  and  SUBJECT  of  the  message.  The  BODY  column  can 
contain  the  entire  messaqe  or  the  name  of  a  text  table.  For 
example,  Figure  2.15  shows  that  message  1  contains  the 
entire  message  body.  Message  2  contains  the  name  of  a  text 
data  table  in  the  text  directory  table.  The  mail  table  can 
be  directly  viewed  by  the  user  as  a  summary  of  the  messages 
but  should  be  reformatted  to  read  or  edit  a  sinole  messaqe. 
5.  Electronic  Spread  Sheet  Tables 
a.   SDread  Sheet  Directory  Table 

The  spread  sheet  directory  table  contains  a  row 
for  eacr\  spread  sheet  data  table.  The  standard  application 
directory  schema,  Figure  2.1s,  is  used. 


ID 


NAME 


COLUMNS 


ACCESS 
CONTROL 


T!\flLE 
POINTER 


VIRTUAL 


CONDITION 


GLOBAL 


DES- 
CRIPTION 


Fiaure  2.16  -  Spread  Sheet  Directory  Table  Schema 


The  GLOBAL  data  items  define  the  recalculation  order, 
default  format,  and  any  other  information  applicable  to  the 
referenced  spread  sheet  data  table. 


2P 


b.   Spread  Sheet  Data  Table  Schema  Table 

The  spread  sheet  data  table  schema  table,  Figure 
2.17,  contains  the  predefined  columns  of  the  spread  sheet 
data  table.  ID  is  the  primary  *ey  of  the  spread  sheet  data 
table.  The  other  columns  contain  the  data  to  calculate  the 
value  of  ar\  entry  position  and  construct  the  user  view  of 
the  sDread  sheet  data  table. 


ID    NAME    TYPE   WIDTH  SYNONYM 


TABLE 


ACCESS 
CONTROL 


1 

ID 

IN- 
TEGER 

NONE 

ALL 

read:  all 
write:  DBA 
modify:  DBA 

2 

X 

INDEX 

CHAP 

NONE 

ALL 

read:  all 
write:  all 
modifv:  DBA 

3 

Y 
INDEX 

IN- 
TEGER 

NONE 

ALL 

read:  all 
write:  all 
modify:  DBA 

4 

FORMAT 

CHAR 

NONE 

ALL 

read:  all 
write:  all 
modify:  DBA 

5 

VALUE 

CHAR 

NONE 

ALL 

read:  all 
write:  all 

modify:  DBA 

6 

FUNC- 
TION 

CHAR 

NONE 

ALL 

read:  all 
write:  all 
modify:  DBA 

Fioure  2.17  -  Spr^96    Sheet  Data  Table  Schema  Ta^le 
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c.   Spread  Sheet  Data  Table 

A  spread  sheet  data  table  contains  the  formatted 
data  to  calculate  the  values  of  and  disolay  a  numerical 
model.  The  spread  sheet  data  table  Is  described  by  the 
COLUMNS  and  DESCRIPTION  columns  in  the  soread  sheet 
directory  table.  A  spread  sheet  data  table,  Fiaure  2.15?,  is 
oointed  to  by  a  TABLE  PQINTSR  in  the  SDread  sheet  directory 
table. 


ID   X 


FORMAT    VALUE    FUNCTION 


1 

A 

1 

INTEGER 

RIGHT 

3 

5 

5 

2 

A 

2 

INTEGER 

RIGHT 

3 

5 

5 

n 

A 

3 

INTEGER 

RIGHT 

3 

10 

Al  +  A  2 

Figure  2.19  -  Spread  Sheet  Data  Table 


The  spread  sheet  data  table  can  be  considered  to  be  the 
tabular  representation  of  the  traditional  spread  sheet  view, 
Figure  2.19,  or,  conversely,  the  traditional  SDread  sheet 
view  can  be  regarded  as  one  disDiay  mode  of  the  soread  sheet 
data  table.  Each  entry  oosition  in  the  view  is  defined  by 
one  row  in  the  spread  sheet  data  table. 
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A 

1  5 

2  5 

3  10 


Figure  2.19  -  Spread  Sheet  View 


The  ID  Is  the  display  order  of  the  sDread  sheet 
data  table  but  does  not  Drovlde  the  ordering  for  the  entry 
positions  in  the  spread  sheet  view.  The  x  and  Y  INDEX 
columns  represent  the  relative  position  of  the  entry 
Dosition  in  the  soread  sheet  view.  The  mapoing  of  the  X  and 
Y  indices  to  the  display  is  contained  in  the  GLOBAL  column 
of  the  soread  sheet  directory  table.  The  FORMAT  column 
contains  the  data  describing  the  display  of  the  entry 
oosition,  A  numeric  value  of  an  entry  Dosition  can  be 
disdayed  as  an  Integer,  floatina  ooint,  or  dollar  and  cents 
number.  The  format  information  also  indicates  whether  the 
values  should  be  ricjht  or  left  justified  and  the  width  of 
the  entry  position  in  the  display.  The  value  column 
contains  the  displav  value  of  the  FUNCTION  column.  The 
FUNCTION  column  contains  an  exoression  which  is  used  to 
determine  the  value  of  the  entry  position.  The  expression 
could  be  tne  typical  constant,  literal,  or  arithmetic  tvpes, 
or  could  be  a  database  auery,  or  a  pointer  to  any  other  IASS 
data  table.  The  oDerands  of  an  expression  can  be  any 
constant  value  or  the  value  of  another  entry  oosition  in  the 
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spread  sheet.  An  operand  value  can  also  be  an  arithmetic, 
trigonometric,  or  some  other  predefined  function,  which  /ran 
use  the  value  of  another  entry  position  as  a  parameter. 
Usinq  the  value  of  another  entry  position  as  an  oDerand  in 
an  expression  is  necessary  to  support  dynamic  modeling,  i.e. 
when  a  chanoe  is  made  to  one  entry  position,  it  is 
immediately  reflected  in  the  entire  soread  sheet  view.  As  a 
matter  of  fact,  the  freedom  to  define  value  of  one  entry 
position  in  terms  of  any  other  entry  position  resulted  in 
one  data  table  structure  and  it  also  prevented  us  from  using 
the  dataoase  intearity  enforcement  mechanism  for  the  SDread 
sheet  view. 
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III.   CONCEPTUAL  INTEGRATION 

A.   OVERVIEW 

The  main  design  objective  of  the  Integrated  Application 
Software  System  CIASS)  is  to  oresent  the  user  with  a  sinole 
conceptual  view  of  the  system  reoardless  of  the  context  of 
its  use.  From  the  user's  perspective,  there  is  only  one  data 
object,  the  table.  As  was  indicated  in  Chapter  2,  dependina 
on  the  level  of  experience  or  intent  of  the  user,  a 
translation  may  be  required  to  reformat  a  data  taole.  This 
translation  is  from  table  to  table  and  therefore,  the  notion 
of  a  sinqle  data  object  is  preserved. 

At  the  conceptual  level  of  each  application  there  is  a 
common  set  of  table  operators  and  a  set  of  application 
soecific  table  operators.  The  common  set  of  table  operators 
represents  the  transportable  Knowledqe  of  tne  system  as  tne 
user  loaically  traverses  between  applications.  The  user  must 
learn  or  be  cognizant  of  only  the  application  specific 
operations  as  the  system  use  chanaes. 

By  functionally  categorizing  each  data  manipulation 
operations  on  the  logical  file  of  tne  non-DBMS  applications, 
an  Intersection  can  be  deduced.  The  intersection  is 
comprised  of  operations  to  locate,  insert,  modify,  delete, 
copy,  and  move  data  in  a   file.    These   operations   can   be 
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integrated  at  the  conceptual  level  by  a  set  of  six  basic 
IASS  primitive  table  operators  based  on  the  relational 
algebra.  This  chaDter  demonstrates  how  the  data 
manipulation  operations  of  each  selected  application  can  be 
mapped  into  the  conceptual  level  primitives.  Although  not 
the  main  intent  of  this  chapter,  where  appropriate, 
extensions  to  the  typical  operation  are  suggested, 

B.  BASIC  IASS  PRIMITIVES 

The  six  basic  IASS  primitives  which  can  perform  the 
operations  in  the  functional  intersection  are  INSERT, 
MODIFY,  DELETE,  PROJECT,  SELECT,  and  UNION.  Each  primitive 
is  set  theoretic  in  that  the  operands  are  tables  and  the 
results  are  tables.  A  table  can  contain  any  number  of  rows. 
A  special  table,  BLANK,  is  defined  to  be  a  row  with  all 
columns  blank  except  for  the  ID.  A  literal  string, 
'literal',  can  stand  for  any  character  string  in  which  It  is 
contained.  What  follows  is  a  description  of  the  primitives. 
For  this  discussion  the  following  conventions  will  be  used: 

CD   The  word  table  is  synonymous  with  data  table 

(2)  Whenever  two  tables  are  used  in  ar\  oceration, 
tablet  and  table2,  tablel  will  be  the  current  table. 

(3)  Column  names  will  aopear  in  uooer  case,  their  value 
will  be  appear  in  lower  case. 
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1 .  Insert 

Given  tablel,  INSERT  adds  table2  at  a  specified 
location.   The  operator  is  denoted: 

INSERT (location,  table2,  tablel) 

2.  Modify 

Given  a  table,  MODIFY  changes  the  value  of  the 
columns  in  the  rows  of  the  table.   The  operator  is  denoted: 

MODIFYCCCOLUMN,  column,  new  value)"*",  table) 

where  the  3-tuple  (COLUMN,  column,  new  value)  describes  the 
change  by  column  name,  present  value,  and  the  new  value. 
The  ♦  indicates  that  more  than  one  column  car.  be  modified  bv 
a  single  operation.  If  a  chanae  to  a  column  value  is  to  be 
made  irresDective  of  the  present  value,  e.g.  change  any 
value  in  column  NAME  to  'JONES',  that  desire  can  be 
expressed  oy  a  special  character,  or  wild  card,  daced  in 
the  present  value   Dosition  of  the  3-tuple, 

3 .  Delete 

Given  a  table,  DELETE  deletes  the  set  of  rows  from 
the  table  that  satisfy  a  specified  condition  based  on  the 
column  values.   This  operator  is  denoted: 

DELETECconditior,  table) 

The  ooerands  of  t*e  conditional  statement  are  literal  or 
numeric   constants,   arithmetic   expressions,   or  the  column 
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values  of  the  table.  The  operators  of  the  conditional 
statement  are  the  arithmetic  comparison  ODerators  (<,  >,  s, 
*♦  4*  tit  the  logical  operators  C  -»  ,  a  ,  v  ),  and  the 
arithmetic  operators  (  +  ,  -,  *,  /).  The  delete  operator  also 
creates  a  table  that  contains  the  deleted  rows. 

4.  Project 

Given  a  table,  a  projection  of  the  table  is  made  by 
removino  some  of  its  columns  and/or  rearrangino  some  of  the 
remaining  columns.  A  projection  of  a  table  is  denoted: 

PROJECTCcolumn  list,  table) 

where  column  list  names  the  desired  columns  from  the   table. 

5.  Select 

Given  a  table,  a  selection  returns  the  set  of  rows 
that  satisfy  a  conditional  statement  based  on  the  column 
values.   A  selection  on  the  table  is  denoted  : 

SELECTCconoition,  table) 

6.  Union 

Given  two  tables,  tablel  and  table2,  the  union 
creates  a  table  whose  rows  are  in  tablel  or  table2,  or  both. 
The  union  operation  is  denoted: 

MNI0NCtable2,  tablel) 

The  schema  of  the  resultant  table  will  be  the  same  as 
tablel.   The  columns  in  table2  whose  content  is  not  the  same 
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as  a  column  in  tablel  Will  not  be  in  the  resultant  table. 
There  are  two  differences  between  the  union  and  insert 
ooerators.  First,  union  apoends  table2  to  the  bottom  of 
table  1.  Second,  insert  assumes  that  tables  1  and  2  are  the 
same  tyoe. 

C.   REALIZATION  OF  LOGICAL  OPERATIONS 

This  section  demonstrates  that  the  data  manipulation 
operations  on  the  logical  file  in  the  functional 
intersection  of  each  application  can  be  exoressed  in  terms 
of  the  conceotual  level  Drimitives.  It  will  be  assumed  that 
the  underlyina  system  maintains  the  ID  column  as  rows  are 
moved  in  a  table.  Its  resolution,  therefore,  will  not  be 
discussed. 

1 .   Text  Processor/Form  Generator 

The  command  sets  of  several  text  Drocessors  and  the 
form  generator  facility  of  DBASE  II  and  the  ZIP  form 
generator  were  reviewed,  and  it  was  found  that  the  text 
processor  set  contained  the  set  of  form  generator  commands. 
Therefore,  these  aDDiications  will  be  discussed  together. 

a.   Locate 

Positioning  the  cursor  typically  comprises  a 
larae  portion  of  the  text  orocessor  and  form  aenerator 
©Derations.  The  cursor  can  be  directed  to  a  line  number, 
relative  distance  from  the  current  line,  or  to  a  substring. 
The  result  of  Dositioning  the  cursor  can  be  considered  to  be 
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a  line  reference.  Locatina  a  row  in  the  text  or  form  text 
data  table  Is  done  by: 

SELECTCconditlon,  table) 

Using  the  primitive,  the  text  or  form  text  data  table  can  be 
browsed  by  contiguous  lines  (e.o  ID  £  XI  A  ID  ^  X2),  or  by 
line  content  (e.g.  TEXT  or  FORM  LINE  =  'substring'AC ID  <  id 
+  10)). 

b.  Insert 

Inserting  a  row  into  a  text  or  form  text  data 
table  at  location  ID  is  done  by: 

INSERTCID,  BLANK,  table) 

The  same  primitive  can  be  used  to  insert  an  entire  data 
tabie2  into  the  current  data  tablel  at  location  ID: 

INSERTCID,  table2,  tablel) 

c.  Modify 

Inserting  and  deleting  characters  are 
functionally  eauivalent  in  that  they  are  modifications  to 
the  contents  of  a  file.  Assuming  that  the  desired  row  is 
current,  the  operation  to  modify  the  row  in  a  text  or  form 
text  data  table  is: 

MODIFYC (TEXT  or  FORM  LINE),  'old',  'new',  table) 

The  find  and  reolace  ooeration  is  an  extension  of   inserting 
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or  deleting  characters.  Wltn  this  operation,  a  row  does  not 
have  to  be  previously  selected.  Also,  a  single  change  to  a 
set  of  rows  identified  by  a  conditional  expression  based  on 
their  column  values  can  be  done.  The  find  and  reolace 
©Deration  is  done  bv  the  expression; 


MODIFYCCTEXT  or  FORM  LINE,  'old',  'new'), 
SFLECTCcondition,  table)) 


d.  Delete 

Deleting  a  row  or  set  of  rows   (block),   from   a 
text  or  form  text  data  table  is  done  by: 

OELETECcondition,  table) 

The  condition  can  oe  any  function  of  the  ID  and/or  TEXT  or 
FORM  lime  columns.  This  qeneral ization  enhances  the  typical 
text  Drocessor  or  form  generator  operation  since  rows  can  be 
identified  by  number  or  content  and  a  block  does  not  have  to 
be  a  contiguous  set  of  rows. 

e.  Copy 

CoDying  lines  in  a  text  or  form  text  data   table 
can  be  done  by  the  expression: 

INSERTCID, SFLECTCcondition,  table),  table) 

Any  portion  of  a  text  or  form  text  data  tablel  can  be  copied 
to  or  saved  to  another  tabled  bv  the   expressions: 
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UNIONCSFLECTCcondltion,  tablel),  table2) 

or 
UNiONfDFLETECcondltio-n,  tablel),  table2) 


The  general  nature  of  the  primitives  enhance  the  tyoical 
text  processor  or  form  generator  operation  by  allowina  the 
lines  to  be  identified  by  content  and  not  requirino  that  a 
blocK  be  contiguous.   For  examole,  the  statement: 


UtfIQN(SELECT(TEXT  LINE  =  'AbC'ACID  <  10), 
taclet),  tacie2) 


would  coDy  to  tacle2,  any  line  in*  tablel  with  ID  less  than 
10  and  whose  TFXT  LIME  column  contains  the  character 
substrinq  ABC, 

f .   Move 

*iovina  rows  or  a  bloc*  in  a  text   or.  form   text 
data  table  to  location  ID  is  done  by  the  excressior: 

INSERTCID,  DELETECcondition,  table),  table) 

The  condition  can  be  any  function  of  the  ID  and/or  text  or 
form  LINE  columns.  This  Generalization  ennances  the  tvpical 
text  processor  or  form  generator  operation  *nich  recruires 
that  line  nu^rers  be  known  and  a  Mock  of  lines  be 
continuous . 

2.   Electrorjc  "all 

The  UNIX  mail  utility  is  an  elaborate  system  which 
is  closely  coupled  to  the  operatino  system,  viewed  as  a 
database   table,   the   complexity   is   reduced.    A   set   of 
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essential  mail  operations  were  deduced  from  the  UNIX  mail 
system. 

a.  Locate 

Displaying  messages  for  readlna  or  editing  can 
be  done  by: 

SELECTCcondition,  table) 

Using  the  orimitives,  the  message  to  oe  disdayed  can  be 
described  by  any  condition  of  the  columns  of  the  mail  data 
table.  This  would  oreclude  the  user  from  having  to  Drowse 
the  mail  data  table  first  to  determine  which  messaoes  miaht 
be  of  interest  and  then  listino  them  py  number. 

A  summary  of  the  messaoes  can  be  displayed  by 
selecting  a  set  of  messaoes  which  satisfy  a  condition  and 
then  disolaylng  the  desired  columns: 

PROJECTCcolumn  list,  SELECTCcondition,  table)) 

By  usino  the  primitives,  the  user  is  not  restricted  to  the 
predefined  message  summary. 

b.  Insert 

A  messaae  can  be  created  by  aopending  a  blank 
row  into  the  mail  data  table  and  modifying  its  null 
contents : 


UNIONCBLANK,  table) 
MODIFYCCCOLUMN,  X,    'new'), 

5ELECTC  all  columns  =  0,  table)) 
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Alternately,  a  message  can  be  created  at  any   location,   ID, 
in  tne  frail  table  by  the  expression: 


INSERTCID,  BLANK,  table) 
MODIFYC (COLUMN,  0,  'new'), 

SELECTC  all  columns  =  Jd ,  table)) 


Regardless  of  the  method  used,  the  3-tuple  list  in  the 
modify  ooerator  contains  a  set  of  values  for  each  column  in 
the  mail  table  exceot  the  ID,  The  change  for  each  column  is 
from  null  to  the  desired  value  supplied  by  the  user. 

Messaaes  addressed  to  a  user  can   be   oicfced   up 
from  any  mail  data  table2  by  the  expression: 

UNIONCDELETECTO  =  'user',  table2),  tablel) 

Messages  can  be  Dieted  up  from  a  mall  data  table2  that 
satisfy  any  SDecified  condition  bv  the  general  expression: 

UNIONCDELETECcondition,  tabie2),  tablet) 

Finally,  an  entire  mail  table2  can  be  inserted  into  mail 
tablel  at  location  ID  by: 

INSERTCID,  table2,  tablel) 

c.   Modify 

Assuming  that  a   message  has  been  selected,   any 
field  in  the  message  can  be  edited  by  the  operation: 

MODIFY( (column,  column,  new  value),  table) 
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The  same  change  can  be  made  to  several  messaaes  which 
satisfy  a  specified  condition  by  slightly  modifying  the 
basic  operation: 


MOOIFYC (COLUMN,  column,  new  value), 
SELECTCcondition,  table)) 


d.  Delete 

Messaaes  can  be  deleted  from  a  mail  data  table 
oased  on  any  column  condition  bv  the  expression: 

DELETECcondition,  table) 

Using   the  orimitives,   a   user   is   not   restricted   to   a 

Dredefined  method  of  deleting  messages.   *itn  one  operation, 

any  set  of  messages  can  be  Identified  and  deleted. 

e.  Copy 

There  .nay  o  e  an  occasion  when  a  coov  of  a 
message  in  a  mail  data  table  needs  to  be  made,  Copyina  a 
messaae  can  be  done  by: 

UNiON(SELECTCcondition,  table),  table) 

Messaoes  can  be  copied  or  saved  to  another   mail  data  table2 
by  the  expressions: 


UNIQMCSELECTCconditlon,  tablel),  table2) 

or 
UMIONCDELETECcondition,  tablel),  table2) 
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f.   Move 

Messaqes  in  a  mail  data  taole  are  not  ordered. 
They  can  be  moved  within  a  mail  data  table  to  location  ID  by 
the  expression: 

INSERT f ID, DELETE (condition, table) ,  table) 

3 .   Electronic  Soread  Sheet 

As  was  noted  In  charter  2,  the  typical  spread  sheet 
view  is  not  the  spread  sheet  data  table.  However,  data 
manipulation  operations  on  the  view  can  be  translated  into 
tbe  operations  on  the  soread  sheet  data  table. 

a.   Locate 

Entry  Dositions  in  the  spread  sheet  view  are 
referenced  by  X  and  Y  oosition.  As  a  result  of  the  locate 
oneration,  the  FUNCTION  field  is  displayed,  Locating  entry 
position  c,  r  in  the  table  is  done  by  the  expression: 

PROJECT (FUNCTION,  SELFCT(X  =  c  A  Y  =  r,  table)) 

The  expression  suggests  that  an  entry  oosition  can  be 
located  by  any  other  column  in  the  spread  sheet  data  table 
by  the  exoression: 

OR0JECTCFUNCTT0N,  SELECT ( condi t ion ,  table)) 

A  problem  with  VISICALC  is  that  a  model  cannot  be  debugaed 
very  easily  since  the  only  one  entry  position  can  oe 
referenced  at  any  time.   The  ceneral  nature  of  tne  crimitive 
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operators  enhances  the  debugaing  capability  by  allowing  a 
set  of  entry  positions  to  be  located  in  the  spread  sheet 
data  table  by  any  condition  of  the  column  values.  For 
example,  all  entry  positions  which  have  a  VALUE  greater  than 
10  can  be  found  by  the  single  operation: 

SELECTCVALUE  >  10,  table) 

This  same   action   using   the   VISICALC   command   set   would 
reguire  the  user  to  locate  the  entry  positions  one-by-one. 
b.   Insert 

One  row  in  the  sDread  sheet  view  is  comoosed  of 
C  rows  in  the  spread  sheet  data  taPle  CC  =  nuraaer  of  columns 
in  the  view),  Insertinc  one  row  in  the  screed  sheet  view  at 
r,  is  done  by  C  iterations  of  the  expressions: 


UNIONCBLANK,  table) 
MODIFYCCCX,  Jd,    X  ),CY,  0,    r)), 

SELECT  (X  =  0  a  Y  =  0,  table)) 


In  the  expression,  x  is  an  element  of  the  column  set  <1..C>. 
One  column  in  the  soread  sheet  view  is  composed 
of  R  rows  in  the  spread  sheet  data  table  CR  »  number  of  rows 
in  the  view),  Insertino  a  column  in  the  soread  sheet  view 
at  d,  is  done  by  R  iterations  of  the  expressions: 


UNIPNCBLANK,  table) 
*0DIFY(C  (X,0,d)  ,(Y,J0,y))  , 

SELECTCX  =  0AY  =  6,    table)) 


In  the  expression,  y  is  an  element  of  the  row  set  <1..R> 
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Two  spread  sheets  can  &e  apoended  together  to 
form  one  composite  table  by: 

UNiON(table2,  tablet) 

Following  a  row  or  column  insertion,  further 
processing  has  to  be  done  to  move  the  successor  rows  or 
columns  in  trie  soread  sheet  view.  Moving  rows  or  columns  is 
discussed  in  subsection  f.  After  the  ro*s  or  columns  are 
moved,  the  entry  positions  that  use  tne  value  of  a  moved 
entry  position  as  an  operand  in  the  FUNCTION  column  must  be 
found  and  modified.  This  process  is  described  in  suDsection 
c.  Finally,  the  modified  FUNCTION'S  must  oe  evaluated  and 
the  new  entry  oosition  VALUE  disolayed. 
c.   Modify 

A  value  or  lanel  entry  oceration  in  VISICALC  is 
ione  to  cnanae  the  value  of  the  FUNCTION  column  of  the 
current  entry  position.   The  expression  is: 

MCDIFYCCFUN'CTION,  function  ,  new  function),  table) 

Movino  an  entry  oositlon  (X  =  e,  Y  =  c),  in  the 
spread  sheet  view  by  changing  the  X  or  Y  value  (X  =  c,  Y  = 
r)  may  reauire  a  subseauent  modification  to  the  FUNCTION 
column  of  the  entry  positions  that  use  e,  c  as  an  ooerand. 
The  Drimitive  expression  to  find  and  modify  all  of  these 
deoendent  entry  oositions  is: 
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MODIFY ((FUNCTION,  'ec',  'cr'), 

SELECTCFUNCTICN  =  'ep',  table)) 


The  current  entry  position  can  be  blanked  by  the 
expression: 

MODIFYCCFUNCTION,  function,  0) ,    table) 

Clearlna  all  entry  cositions  in  the  spread  sheet  view  can  be 
done  as  a  special  case  of  the  blanKina  action  previously 
described.  Instead  of  the  table  beinq  a  previously 
selected  row,  it  is  in  tnis  case,  the  entire  table: 

MODIFY( (FUNCTION,  function,  0) ,  table) 

After  modifyino  the  FUNCTION  column  of  an  entry 
position,  the  FUNCTION  must  be  evaluated  and  the  new  entry 
Dosition  VALUE  displayed. 

The  VISICALC  format  commands  deal  with  the 
visual  display  of  entry  positions.  Formatting  an  entry 
position  reauires  a  modification  to  the  format  column  in  the 
spread  sheet  data  table.  Chanoino  the  format  of  the  current 
entry  position  Is  done  by: 

MODIFYC (FORMAT,  format,  new  format),  table) 

One  format  chanae  can  be  made  to  a  set  of  entrv  positions 
which  satisfy  a  specified  condition  by  tne  ooeration: 


MODIFYC (FORMAT,  format,  new  format), 
SELFCTCcondition,  table)) 
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d.   Delete 

One  row  from  the  spread  sheet  view  can  be 
deleted  with  the  VISICALC  command  set.  Since  one  row,  r,  In 
the  view  Is  composed  of  C  rows  In  the  spread  sheet  data 
table,  (C  a  total  number  of  rows  in  the  view)  that  many  must 
be  deleted  from  the  spread  sheet  data  table.  The  operation 
is: 

DELETECY  =  r,  table) 

Although  the  VISICALC  command  set  does  not  allow  multiple 
rows  to  be  deleted,  the  basic  delete  ooeration  can  be 
modified  to  delete  a  block  (Yl  through  Y2)  in  the  spread 
sheet  view: 

DELETECY  ^  YlA  Y  «  Y2,  table) 

Deletina  a  column  is  similar  to  deletina  a  row. 
Since  a  column,  c,  in  the  spread  sheet  view  is  composed  of  R 
rows  CR  =  number  of  rows  in  the  view)  in  the  spread  sheet 
data  tabl<»,  that  many  are  deleted  by  the  sinale  expression: 

DELETECX  =  c,  table) 

This  operation  can  be  enhanced  to  allow  the  deletion  of  a 
set  of  columns  CXI  through  X2): 

DELETECX  ^  X1A  X  $  X2,  table) 
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Followinq  a  row  or  column  deletion,  further 
processing  is  needed  on  the  table.  In  the  view,  a  deletion 
requires  that  all  rows  and  columns  be  moved  to  fill  in  the 
blank.  Moving  rows  and  columns  is  discussed  in  subsection 
f.  After  the  rows  or  columns  are  moved,  all  of  the 
dependent  tuoles  must  be  found  and  their  FUNCTIONS  modified 
to  correspond  to  the  new  positions.  Finally,  the  modified 
FUNCTIONS  must  be  evaluated  and  the  new  entry  position 
VALUES  diSDlayed. 
e.   Copy 

CoDying  the  current  entry  Dosition  (X  a  e,  Y  = 
o),  to  any  other  position  (X  a  c,  Y  =  r),  in  the  spread 
sheet  view,  can  be  done  by  the  expression; 


MODIFYC (COLUMN,  column,  (e , o) .column ), SELECT CX  =  cA 

Y  a  r,  table)) 


If  the  destination  entry  position  (X  a  c,  Y  =  r)  is  not 
found,  a  new  tuple  must  be  entered  into  the  spread  sheet 
table  and  its  null  contents  modified: 


UNiCNCaLANK,  table) 

MODIFYCCCOLUMN,  IS,     C  e  ,  p  ).  column)  ,  SELECTCX  =  0A 

Y  a  J0T,  table)  ) 


For  the  entry  position  (X  =  c,  Y  =  r),  the  3-tuole  list 
contains  a  change  for  each  column  except  X  and  Y,  to  the 
value  of  the  same  column  in  entry  position  at  CX  a  ey  Y  a  p). 
Although    order    in    the    spread   sheet   data   table   is 
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insignificant,  the  entry  position  can  be  copied  to  a 
specified  location  by  substituting  the  insert  operator  for 
the  union  in  the  previous  expression: 

INSERTCID,  BLANK,  table) 

A  column  of  height  h,  can  be  created  in  the 
view  by  making  h  coDies  of  the  entry  position  at  X  ■  e  Y  = 
p.  In  the  spread  sheet  data  table,  the  operation  can  be 
done  by  selecting  the  rows  with  a  Y  value  in  the  height 
ranne  Cr  through  s)  of  the  column,  c,  in  the  view,  and 
making  the  same  chanae  to  the  VALUE,  FUNCTION,  and  FORMAT 
columns.  The  operation  is: 


MODIFYt (COLUMN,  column,  (e , p ) .column) , SELECT CX  ■  cA 
CY  ^  r A  Y  ^  s) ,  table) ) 


Copying  a  column  of  height  h,  can  be  done  by 
making  h  calls  to  the  copy  one  entry  Dosition  orocess.  On 
each  call,  the  Y  value  for  both  the  origin  and  target  entry 
position  is  incremented  by  one. 

Makina  n  cocies  of  one  column  can  be  done  by 
making  n  calls  to  the  cony  one  column  process.  On  each 
call,  the  X  value  is  changed. 

Copying  a  row  of  lenath  1,  can  be  done  by  making 
1  calls  to  the  copy  one  entry  oosition  process.  On  each 
call,  the  X  value  for  both  origin  and  target  entrv  Dosition 
is  incremented  by  one. 
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Makina  m  copies  of  a  row  could  be  done  by  makina 
m  calls  to  the  copy  one  row  Drocess.  On  each  call,  the  Y 
value  would  be  chanaed. 

Any  rectangular  portion  of  a  soread  sheet  view 
in  soread  sheet  tablet,  CY1  through  Y2)  by  CXI  through  X2), 
can  be  cooled  to  or  saved  to  another  spread  sneet  in  soread 
sheet  taole2.   This   ©Deration  is  done  by  the  exoression: 


UNIONCSELECTCCY  >,    YlAY  $  Y2)A(X  ^  X1AX  N<  X2),  tablel), 
table2) 

or 
UNIONfDELETEC CY  £  YlAY  «  Y2)A(X  £  X1AX  <  X2),  tablet), 

table2) 


f.   Move 

A  row  move,  from  r  to  s,  in  the  soread  sheet 
view  can  be  done  in  the  table  by  modifyina  the  Y  value  of 
the  C  rows  in  the  spread  sheet  data  table.  The  expression 
is: 

MODIFYCCY,  r,  s),  SELECTCY  =  r,  table)) 

A  set  of  rows  (r  throuoh  s)  can  be  moved  by  the  same 
exoression  with  a  different  with  a  different  set  of 
parameters : 

MODIFYCCY,  y,  y  -  lr  -  si),  SELECTCY  >,    rAY  £  s,  table)) 

This  exoression  is  for  the  case  where  tne  set  of  rows  is 
moved  up.  To  move  the  set  of  rows  down,  the  new  value  in  the 
3-tuple  would  nave  to  be  modified  to  y  +  lr  -si. 
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Moving  a  column  in  the  spread  sheet  view  is  done 
with  the  same  primitives.  The  process  will  not  be 
reiterated  except  to  mention  that  each  occurrence  of  Y  in 
the  original  expressions  would  have  to  be  changed  to  X. 

After  moving  rows  or  columns,  deoendent  entry 
positions  have  to  be  found  and  their  FUNCTION  columns 
modified  to  reflect  the  new  Dositions.  Finally,  the 
modified  FUNCTIONS  must  be  evaluated  and  the  new  entry 
position  VALUE  displayed  in  the  view. 
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-  IV.   IASS  EXTENSIBILITY 

A,   COMBINING  IASS  TABLES 

From  the  review  of  the  commercial  application  systems, 
It  is  clear  that  the  non-DBMS  applications  selected  for  this 
study  Drovide  functions  to  manipulate  data  in  one  looical 
file.  Combining  files,  of  the  same  tyoe,  can  be  done  by 
appending  files  together  or  inserting  one  into  another.  As 
a  result  of  these  file  combinations,  however,  no  new 
relationships  are  developed  nor  can  information  be  deduced 
from  the  action.  Using  the  relational  database  model  as  tne 
common  data  model,  there  are  a  set  of  binarv  or?eretors  which 
can  be  used  to  combine  taoles  to  form  new  relationshios  and 
derive  information.  These  onerators  UNION,  SET  DIFFERENCE, 
INTERSECTION,  JOIN,  and  NATURAL  JOIN  are  defined  in  Ullman 
CRef.  23.  This  chapter  explores  the  semantics  of  comoining 
the  data  tables  by  these  ooerators.  Speculation  of  this 
nature  can  result  in  numerous  table  combinations  which  could 
ootentially  define  a  new  application.  This  review  is  not 
Dresumed  to  be  exhaustive,  but  merely  sugaests  the 
meaninaf ulness  of  and  potential  uses  for  the  IASS  table 
combining  operators. 
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B.   INTRA  TYPE  COMBINATIONS 

This  section  considers  the  effect  of  combining  data 
tables  of  the  same  type  by  the  operators  SET  DIFFERENCE, 
INTERSECTION,  JOIN,  and  NATURAL  JOIN.  The  UNION  ooerator 
will  not  be  discussed  since  each  application  can  use  it  to 
support  an  existing  function. 

1  ,   Text/Form 

Due  to  the  similarities  in  the  text  and  form  tables, 
the  semantics  of  the  intra  table  combinations  will  be 
discussed  together. 

a.   Set  Difference 

The  set  difference  ooerator  would  be  meanlnqful 
within  the  context  of  text  Drocessing  and  form  aeneratina. 
It  could  be  used  in  applications  which  reouire  a  line-by- 
line comoarison  between  two  tables.  For  example,  it  is 
often  necessary  to  compare  two  versions  of  the  same  computer 
program  in  the  course  of  oroaram  development  or  two  versions 
of  the  same  form  during  design.  By  apolying  the  set 
difference  ooerator  on  two  tables  R  and  S,  a  listing  of  all 
the  lines  in  R  that  are  not  duplicated  in  S  would  be 
returned. 

The  set  difference  operator  would  also  be  useful 
in  an  application  to  extract  entire  sections  from  a  table. 
Used  in  this  way,  the  ooerator  would  represent  the  inverse 
of  the  union  or  insertion  ooerators  to  build  a  composite 
table.   From  the  composite  table  R,  those  same  sections,   S, 
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could  be  directly  removed  by  performing  a  set  difference. 
Similarly,  the  set  difference  could  also  be  useful  to  remove 
lines  from  a  table,  R,  that  were  contained  in  table,  S. 

b.  Intersection 

The  intersection  of  two  tables  would  be 
meaningful  within  the  context  of  text  Drocessina  or  form 
generation.  It  could  be  used  in  aopiications  requiring  a 
line-by-line  comoarison  or  to  match  substring  patterns  of 
two  tables  to  determine  their   similarities.    For   example, 

• 

comparing  versions  of  the  same  table  to  check  their 
consistency  could  be  done  by  taking  the  intersection.  This 
operator  also  sugaests  that  two  unrelated  tables  could  be 
compared  to  determine  their  "closeness".  The  resultant 
table  could  ce  used  to  deduce  'similarities  between  the  two 
tables  based  on  the  fact  that  they  contained  identical 
lines,  or  used  to  selectively  remove  duolicate  lines  from 
either  table, 

c.  Join 

Joining  two  text  tables  or  form  text  tables 
would  be  meaningful.  It  could  be  used  in  an  aDplication 
which  reguired  two  tables  to  be  in  context  simultaneously. 
For  example,  tables  eguiloined  on  their  ID  number  would 
produce  a  split-screen  effect  to  review  and  edit  them 
side-by-side.  This  combination  would  be  oarticularly  useful 
if  the  contents  of  one  table  was  dependent  on  or  related   to 
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the   contents   of   the  other.   The  same  operation  would  be  a 
method  to  produce  a  multi-columned  table  from  two  tables. 

Joining  two  tables  would  also  be  useful  in 
applications  which  reauired  a  comparison  of  the  lines  of  two 
tables.  Because  the  join  performs  a  cartesian  product  it 
would  be  unlikely  that  lines  could  be  compared  other  than  as 
to  their  equality.  Since  the  join  uses  a  selection 
ooerator,  the  join  could  determine  equality  by  matchina  a 
line  in  R  as  a  substring  in  S  or  vice  versa.  An  equijoin  on 
the  contents  in  two  tables  would  produce  a  table  which  would 
list  the  lines  in  R  next  to  the  lines  S  that  were  equal. 
This  could  be  used  to  determine  the  similarity  between  two 
tables  with  finer  resolution  than  that  available  by  takinc 
the  intersection, 

d.   Natural  Join 

To  do  a  natural  join  of  text  tables  or  form 
tables  would  be  meaningful,  A  natural  join  between  two 
tables  would  produce  similar  results  as  those  obtained  by 
doinq  an  intersection  or  an  equijoin  on  the  table  contents, 
An  apolication  in  which  the  natural  join  could  be  used  would 
again  be  to  produce  a  table  based  on  the  equality  of  lines 
contained  in  two  seoarate  tables.  Instead  of  creating  a 
table  which  contained  a  line  from  each  tade  in  one  row,  the 
resultant  table  would  contain  only  lines  from  one.  As  with 
the  eouijoin,  the  lines  returned  could  be  a  substrino  match. 


56 


2.      Mall 

a.  Set  Difference 

The  set  difference  operator  would  be  meaningful 
in  a  mall  utility.  An  apollcatlon  In  which  the  operation 
would  be  useful  is  to  eliminate  duplicate  messages  from 
several  mail  tables. 

b.  Intersection 

The  intersection  of  two  mail  tables  would  be 
meaningful.  By  doing  an  intersection,  dUDlicate  messages 
could  be  located  in  several  mail  tables.  This  information 
could  be  used  to  selectively  manage  the  message  tables  and 
control  the  number  of  message  copies  in  the  entire  system. 

c.  Join 

The  join  of  two  mail  tables  would  be  useful  in  a 
mail  utility.  It  could  be  used  In  an  aooilcation  such  as 
automatic  readdressing.  For  examole,  consider  the  set  of 
messages  that  have  the  same  subject.  A  recipient  could  be 
in  mail  table  R  by  virtue  of  the  fact  that  it  has  received 
at  least  one  message  oertaining  to  the  subject.  This  mail 
table  In  effect  would  reoresent  a  channel  defined  bv  the 
common  subject.  As  messaaes  are  received  in  the  mail  table 
S,  an  eguijoin  on  the  SUBJECT  column  between  mail  table  R 
and  mail  table  S  followed  by  a  projection  of  R. header  and 
S.Body  would  create  a  cooy  of  the  new  messaae  for  each 
recipient  in  mall  table. 
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The  join  of  two  mall  tables  would  also  be 
meaningful  in  an  ad  hoe  aoplication  to  find  messages  in  two 
mail  tables  whose  fields  have  a  specified  relationship.  For 
example,  a  join  could  be  done  to  return  all  of  the  messaaes 
in  R  and  S  such  that  they  were  from  the  same  addressee  but 
the  messages  in  S  were  dated  after  the  messages  in  R. 
d.   Natural  Join 

A  natural  join  on  two  mail  tables  would  be 
meaningful.  Since  the  BODY  column  of  a  message  is  textual, 
two  messaaes  could  be  considered  to  be  egual  if  one  was  a 
substring  match  of  the  other.  A  natural  join  on  two  mail 
tables  R  and  S  would  therefore,  return  all  messages  in  R 
whicn  had  the  same  header  as  a  message  in  S  and  whose  body 
was  either  duoiicated,  a  subset  of,  or  a  superset  of  the 
body  of  the  messaoe  in  S. 
3.   Soread  Sheet 

a.   Set  Difference 

The  set  difference  operator  would  be  meaningful 
in  a  SDread  sheet  application.  It  could  be  used  to  compare 
two  instances  of  the  same  model.  For  example,  if  snread 
sheet  R  contained  a  model  with  one  set  of  Darameters,  and 
soread  sheet  S  contained  the  same  tiodel  with  a  different  set 
of  oarameters,  the  set  difference  would  produce  a  spread 
sheet  view  which  showed  each  entry  oosition  in  R  that  was 
different  in  S. 
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b.  Intersection 

An  intersection  of  two  spread  sheet  tables  would 
be  meaningful.  It  could  be  used  to  produce  a  soread  sheet 
used  to  compare  different  instances  of  the  same  model.  The 
resultant  table  in  this  application  would  show  the  entry 
positions  that  remained  constant  aiven  a  different  set  of 
parameters. 

c.  Join 

The  join  of  two  spread  sneet  tables  would  be 
meaningful.  If  the  spread  sheets  were  the  same  model  with 
different  parameters,  an  eguijoln  on  the  position  fields 
would  be  a  way  to  produce  a  table  so  that  two  spread  sheets 
could  be  compared  side-by-si^e.  A  orocess  could  be 
developed  which  could  be  used  to  toggle  between  the  soread 
sheet  in  view.  in  this  way,  pach  spread  sneet  maintains  it 
logical  independence, 

A  join  between  two  soread  sheet  taoles  would  be 
the  only  way  their  contents  could  be  comDared  by  column 
relationships.  For  example,  a  join  could  be  done  to 
directly  determine  the  differences  between  two  instances  of 
the  same  model  or  the  same  instance  of  a  problem  in  two 
different  models.  The  join  on  R  and  S  such  that  the  X  and  Y 
positions  were  the  same  but  the  VALUE  in  R  was  in  a 
specified  relationshiD  to  the  VALUE  in  S  would  return  a 
table  which  contained  the  entry  positions  in  R  and  S  which 
satisfied  the  condition. 
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d.   Natural  Join 

A  natural  join  on  two  spread  sheet  tables  would 
produce  the  same  effect  as  the  Intersection. 

C.   INTER  TYPE  COMBINATIONS 

This  section  considers  the  effects  of  combining  data 
taDles  of  different  tyoes  by  the  operators  UNION,  SET 
DIFFERENCE,  INTERSECTION,  JOIN,  and  NATURAL  JOI*J.  Some 
table  operations  are  not  syntactically  feasible  on  certain 
table  types  and  therefore  are  not  addressed, 
1,   Text 

a.   Union 

The  union  between  a  text  table  and  a  form  table 
would  be  meaningful.  For  example,  the  body  of  a  letter  can 
be  Kent  in  a  text  table.  By  unioning  it  to  a  form  table 
containlno  a  letter  head,  a  form  letter  would  be  created. 

The  union  between  a  text  table  and  mail  table 
would  be  meaningful.  An  application  in  which  this  ooeration 
would  be  useful  to  create  a  text  table  from  the  Dodies  of 
several  messages  in  a  mail  data  table. 

The  union  between  a  text  table  and  a  sDread 
sheet  table  would  be  meaningful.  By  anpending  a  soread 
s*eet  table  onto  a  text  table,  the  FUNCTION  column  data 
could  be  included  in  a  text  table,  possibly  to  be  sent  to  an 
individual  in  a  letter. 
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The  union  between  a  text  table  and  a  database 
table  would  be  meaningful.  If  a  database  table  contained  a 
textual  column,  for  example  a  literal  description  of  an 
object,  the  data  in  that  column  could  be  included  in  a  text 
table.  Conversely,  a  textual  description  about  an  object 
could  be  kept  in  a  text  table.  By  unionino  the  text  table 
onto  the  database  table,  the  data  for  the  textual  column 
would  be  provided. 

d.   Set  Difference 

The  set  difference  between  a  text  table  and  a 
form  table  would  be  meaningful.  An  application  to  remove 
text  lines  from  a  text  table  which  were  also  in  a  form  could 
use  the  set  difference.  A  set  difference  between  a  text 
table  and  any  of  the  other  table  types  would  not  be 
syntactically  meaninaful. 

c.  Intersection 

The  intersection  between  a  text  table  and  a  form 
table  would  be  meaningful  in  an  apDlication  to  determine  the 
text  lines  that  were  common  in  the  tables.  By  this 
operation  it  could  be  determined  if  a  form  letter  contained 
the  a  body  stored  in  the  text  table.  An  intersection 
between  a  text  table  and  any  of  the  other  table  types  would 
not  be  syntactically  meaningful. 

d.  Join 

A  join  between  a  text  table  and  a  form  table 
would  be  meaningful,   A  text  table  can  De  joined  with  a  form 
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table  on  the  ID  fields  which  could  be  used  to  produce  a  form 
with  a  textual  description.  Either  portion  of  this 
composite  table  could  be  separately  edited.  An  eauijoin  on 
the  lines  of  the  text  and  form  tables  would  return  the  lines 
which  were  common  in  both  tables, 

A  join  between  a  text  table  and  a  mail  table 
would  be  meaninoful.  If  the  text  table  had  one  subject  on 
each  TEXT  LINE,  by  doing  an  equijoin  on  the  TEXT  LINE  and 
the  message  SUBJECT,  a  text  table  can  be  created  which 
contains  the  message  bodies  pertaining  to  a  set  of  subjects 
which  are  of  interest.  This  could  be  a  method  of  collating 
the  messages  from  several  system  users  concernina  a 
particular  subject  into  a  single  document, 

A  join  between  a  text  table  and  a  database  table 
would  be  meaningful.  For  example,  if  a  database  table 
contained  a  textual  column,  the  column  in  the  database  table 
could  contain  the  ID  of  a  text  line.  An  equijoin  on  the 
database  column  and  text  line  would  suoply  the  text  for  the 
database  tuple.  One  text  line  could  be  contained  in  several 
of  the  database  tuples  and  by  maintaining  one  cooy  of  the 
textual  contents,  all  tuples  will  be  assured  of  havino  the 
same  textual  column  value.  If  the  database  table  contained 
a  mailina  list,  a  join  on  the  database  table  and  the  text 
table  would  be  the  procedure  by  which  a  copy  of  the  text 
table  could  be  made  for  each  entry  in  the  list.  Another 
application  in  which  a  join  would  be   meaningful   between   a 
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text  table  and  database  table  is  where  the  database  contains 
a  set  of  keywords  or  Key  ohrases.  By  doinq  an  equijoin  on 
the  TEXT  LINE  and  the  Keywords  or  Key  phrases,  every  line  in 
the  text  table  containing  the  Keywords  or  Key  phrases  would 
be  returned.  The  same  application  also  suggests  that  the 
combination  could  be  used  in  support  of  a  word  che.cKing 
orogram.  Separate  dictionaries  can  be  maintained  in  a 
database  table  and  joined  with  a  text  table.  The  resultant 
tables  could  be  used  to  checK  spelling  or  to  analyze  a 
particular  style  of  writing, 

A  Join  between  a  text  table  and  a  spread  sheet 
table  would  be  meaningful.  A  narrative  description  about 
one  model  could  be  maintained  in  a  text  table.  Since  it  is 
common  to  store  the  same  model  with  different  oarameters  in 
several  spread  sheets,  one  text  table  could  be  loined  to  the 
spread  sheets  by  ID  number  to  document  the  model.  This 
would  be  useful  to  the  user  viewing  the  spread  sheet  table. 
To  contain  this  additional  information  in  the  view,  would 
require  an  application  SDecific  orocess  which  would  disolay 
the  additional  field, 

e.   Natural  Join 

The  natural  join  between  a  text  table  and  form 
text  taole  would  be  meaningful  since  the  column  names  are 
synonymous.  It  could  be  used  to  determine  the  lines  of  text 
contained  in  Poth  tables.  The  resultant  table  would  be  the 
same  as  that  returned  by  taking  the  intersection. 
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2.   Form 

a.  Union 

The  union  between  a  form  text  table  and  a  text 
table  would  be  meaningful.  An  application  in  which  this 
operation  would  be  useful  would  be  to  generate  a  form  letter 
as  was  addressed  in  subsection  1.  The  union  between  a  form 
text  table  and  a  mail  table  would  be  meaningful.  The  body  of 
a  message  could  be  a  FORM  LINE.  By  unioning  the  form  table 
and  the  mail  table,  a  form  sent  line-by-line  through  the 
mail  facility  could  be  regenerated. 

b.  Set  Difference 

The  set  difference  between  a  form  text  table  and 
text  table  would  be  meaningful.  In  a  similar  aDpllcation  as 
that  discussed  in  subsection  1,  the  operation  could  be 
useful  to  remove  a  set  of  text  lines  fro"  a  form.  A  set 
difference  between  a  form  text  table  and  the  other  table 
tyoes  is  not  syntactically  feasible. 

c.  Intersection 

The  intersection  between  a  form  text  table  and  a 
text  table  would  be  meaningful  to  determine  the  common  lines 
of  text  between  the  two  tables  as  was  described  in  subection 
1.  An  intersection  between  a  form  text  table  and  the  other 
table  types  is  not  syntactically  feasible. 

d.  Join 

A  join  between  a  form  text  table  and  text  table 
would   be  meaninaful  in  aoplications  discussed  in  subsection 
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1.  A  join  between  a  form  text  table  and  a  mail  table  would 
be  meaningful.  A  user  can  sequence  a  FORM  LINES  and  name  the 
form  in  the  SUBJECT  column  and  send  a  form  line-by-line 
through  the  mail  facility.  A  form  text  table  with  one  line 
can  be  created  containing  the  form  name.  By  an  eguijoin  on 
the  FORM  LINE  and  SUBJECT  columns,  all  of  the  FORM  LINES 
could  be  collected  from  the  mail  table.  T*e  form  can  be 
reseouenced  by  the  data  in  the  SUBJECT  column  of  each 
message. 

A  join  between  a  form  text  table  and  database 
table  would  be  meaningful,  A  join  on  the  ID  numbers  between 
a  form  text  table  and  an  associated  database  table  would  be 
useful  to  view  the  two  tables  simultaneously.  The  lines  of 
each  table  in  the  joined  table  could  also  be  edited 
independently  in  this  form, 

A  join  between  a  form  text  table  and  soread 
sheet  table  would  be  meaninqful.  Since  the  FUNCTION  column 
could  contain  a  reference  to  an  entry  in  a  database  table,  a 
form  text  table  and  spread  sheet  table  could  have  a 
relationship  through  a  common  database.  An  eauijoin  on  the 
FUNCTION  column  and  FORM  line  would  return  the  list  of  entry 
oositions  and  form  lines  which  contained  the  same  database 
reference.  In  the  view,  the  spread  sneet  and  the  filled  out 
form  could  be  displayed.  This  would  be  useful  to  show  a 
spread  sheet  model  and  its  Darameter  set  in  a  form  in  one 
view. 
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e.   Natural  Join 

A  natural  join  between  a   form   text   table   and 
text   table   would   be   meaningful  .in   the  same  application 
described  in  subsection  1. 
3.   Mail 

a.   Union 

The  union  between  a  mail  table  and  text  table 
would  be  meaningful.  A  message  can  be  created  by  a  union 
between  a  mail  table  and  text  table  that  contained  a  message 
body  on  one  line.  The  message  header  can  then  be  edited  for 
the  message  created.  Similarly,  a  text  table  of  n  lines 
could  be  unloned  onto  a  mall  table  and  sent  to  a  svstem 
user.  F°OM,  to,  COPY  TO,  ard  DATE  columns  of  n  messaaes 
would  be  the  same.  The  text  table  name  and  ID  can  be  Dlaced 
in  the  SUBJECT  column  to  direct  the  recipient  in  the 
reconstruction  of  the  text  table. 

The  union  between  the  mail  table  and  a  database 
table  containing  a  textual  column  is  meaningful.  The  union 
would  be  useful  to  suDDly  a  messaoe  body  from  the  textual 
column.  The  header  of  the  messaoe  could  then  be  edited. 
This  would  be  a  method  to  send  data  in  a  local  database  to 
any  other  user  in  the  system.  Another  application  for  a 
u^ion  between  a  database  and  mail  table  would  be  to  generate 
a  set  of  message  headers  in  a  database  table.  These  headers 
could  be  unioned  onto  a  mail  table  and  then  the  30DY  columns 
provided. 
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b.   Join 

A  join  between  a  mall  table  and  tne  form  text 
table  and  text  table  is  meaningful.  For  example,  this 
operation  can  be  used  to  send  a  text  table  or  form  text 
table  to  a  system  user  throuqh  the  mail  facility.  A  set  of 
messaoe  headers  addressed  to  the  same  redolent  containina 
an  ID  In  the  BODY  column,  could  be  oreoared  in  the  mail 
table.  By  dolno  an  equijoin  on  the  messaoe  BODY  and  the 
text  or  form  text  ID  columns,  and  removing  the  extraneous 
columns,  a  message  containing  each  line  of  the  form  text  or 
text  table  can  be  created. 

A  join  between  a  mail  table  and  a  database  table 
would  be  meaningful.  For  example,  a  messaoe  could  be 
addressed  to  a  qrouD  of  individuals  recoonized  bv  a  sinole 
name.  A  database  table  could  contain  the  mapoinq  from  that 
sinole  name  to  the  individual  names.  An  equljoin  between  the 
TO  column  of  the  messaqe  and  the  column  containino  the 
aqgreoate  name  in  the  database  would  produce  a  table  wnich 
contains  a  copy  of  the  original  messaqe  for  each  individual 
included  in  the  qroup.  This  ODeration  could  also  be  used  to 
qenerate  a  messaoe.  Havinq  prepared  the  body  of  a  messaqe 
and  usinq  a  standard  subject  line,  a  database  table 
containinq  a  set  of  headers  includino  the  subject,  could  be 
eauijoined  with  a  mail  table  on  the  SUBJECT  columns  to 
Droduce  the  entire  message.  This  messaqe  qeneration  method 
is  particularly  useful  in  a   situation   where   the   standard 
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headers  are  always  belnq  revised.  It  Is  also  useful  when  one 
message  needs  to  be  sent  to  several  different  headers  or 
several  messages  of  the  same  subject  need  to  be  sent  to  the 
same  header. 

Finally,  a  message  can  be  created  by  joining  a 
database  table  containing  a  set  of  messaae  headers  and  a 
text  table  containing  a  message  body  on  each  line.  By 
ecuijoining  the  t«o  tables  on  the  ID  column,  one  heading 
would  be  joined  to  one  body.  A  join  on  any  other  column  in 
the  header,  and  the  TEXT  LINE  would  join  every  header  with 
every  body. 

c,   Matural  Join 

The  natural  join  between  a  mall  table  and 
database  table  would  be  meaninaful.  An  apolication  in  which 
a  natural  join  would  be  useful  would  be  to  supoort  routing 
of  incoming  messages.  For  example,  it  is  often  necessary  to 
route  messages  to  individuals  based  on  the  messaae  subject. 
If  a  database  were  maintained  which  had  fields  for  the 
subject  and  name  of  a  person,  the  mail  table  could  be 
naturally  joined  to  this  list.  The  result  of  the  action 
would  be  a  table  which  contained  a  copy  of  the  message  for 
each  person. 

4.   Soread  Sheet 

a.   Union 

The  union  between  a  spread  sheet  table  and  a 
database  table  would  be  meaningful.   This  operation  could  be 
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useful  In  a  situation  where  a  spread  sheet  must  contain 
standard  entries.  For  example,  a  database  table  could  be 
maintained  with  a  subset  of  the  SDread  sheet  table  columns 
(e.o.  X,  Y,  and  FUNCTION).  This  database  could  be  unioned 
onto  a  spread  sheet  table  to  boiler  Plate  the  soread  sheet 
view. 

b.   Join 

The  join  between  a  spread  sheet  table  and 
database  table  would  be  meaninaful.  For  example,  a  database 
table  could  contain  a  set  of  values  which  are  of  special 
significance.  A  conditional  join  based  on  these  values  and 
the  VALUE  column  in  the  spread  sheet  table  would  return  all 
of  the  entry  positions  which  satisfied  the  condition. 
Another  aoDlication  in  which  this  combination  would  be 
meaningful  would  be  to  store  standard  entry  position 
definitions  in  a  database  table.  An  equijoin  on  the 
position  columns  would  boiler  plate  the  soread  sheet. 
Finally,  an  aDplication  in  which  this  combination  would  be 
meaninaful  is  to  store  a  set  of  Darameters  for  a  spread 
sheet  table  in  a  database  containing  columns  for  X,  Y,  and  a 
vector  containing  the  oarameter  set,  9y  doing  an  equijoin 
on  the  x  and  Y  columns,  and  removing  all  of  the  columns 
except  the  X,  Y,  FORMAT,  VALUE,  and  desired  parameter 
column,  the  parameter  set  is  sucolied  to  the  model. 
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c.   Natural  Join 

The  natural  join  between  the  spread  sheet  table 
and  a  database  table  would  be  meaningful.  A  database  table 
could  contain  documentation  with  respect  to  each  entry 
position  in  the  spread  sheet  table.  By  doing  a  natural  join 
on  the  X  Y  columns,  a  spread  sheet  table  could  be  documented 
tuple  by  tuple.  This  would  especially  be  useful  if  there 
were  instances  of  the  same  model  in  separate  soread  sheet 
tables.  For  this  aoplication,  the  line  documentation  would 
only  have  to  maintained  in  one   database  table. 

A  spread  sheet  can  be  created  from  two  database 
tables.  Database  tablet  could  contain  the  X,  Y,  and  format 
columns  representing  a  Darticular  soread  sheet  format. 
Database  table2  could  contain  the  X,  Y,  VALUE,  and  FUNCTION 
columns  reoresentino  a  standard  model.  By  a  natural  Join  of 
the  two  tables,  a  spread  sheet  containing  a  standard  model 
in  a  selected  format  would  be  oroduced. 
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V.   CONCLUSION 

A.   FINDINGS 

Based  on  this  study,  it  can  be  concluded  that  the 
relational  database  model  can  conceptually  supoort  the  data 
representation  and  manipulation  requirements  of  the  selected 
IASS  aoplications.  At  the  conceptual  level  each  loaical 
file  can  be  represented  as  a  table  and  the  common  data 
manipulation  functions  of  each  aopiicatlon  in  its 
traditional  form  can  be  expressed  in  terms  of  basic  IASS 
primitives.  In  the  IASS,  hiqher  level  apDlication  specific 
functions  can  be  defined  in  terms  of  the  lower  level 
primitives.  For  examole,  the  COPY,  MOVE,  and  FIND  AND 
REPLACE  functions  can  be  expressed  in  terms  of  the  primitive 
Dairs,  INSERT/SELECT,  INSERT/DELETE,  and  MODIFY/SELECT 
respectively.  In  addition  to  the  intersection  of  commands 
and  functions  that  exists  between  the  IASS  applications 
there  exists  an  intersection  of  commands  and  functions 
between  subsets  of  the  apoiications .  For  example, 
formatting  commands  are  apDlicable  if  a  user  is  editino  a 
text  file,  form,  or  message  body.  Also,  aaorecate 
arithmetic  functions  are  common  to  database  and  spread  sheet 
applications.  These  intersections  further  reduce  the  set  of 
aopiicatlon  SDecific  commands  and  functions  a  user  must 
Know. 
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The  IASS  also  contains  a  set  of  four  combining 
operators.  When  used  to  combine  tables  of  the  same  type, 
these  operators  can  be  used  to  deduce  information  about  data 
contained  in  two  tables,  and  to  create  new  tables  from 
existing  tables.  In  this  way,  the  IASS  enhances  the  basic 
capabilities  of  each  of  the  non-DBMS  aDplications. 

By  mapping  the  logical  file  into  one  conceDtual  data 
object,  data  independence  is  achieved.  Therefore,  the  full 
use  of  the  specifically  designed  data  tables  can  be  realized 
by  removing  their  semantic  identity.  A  data  table  can  be 
used  by  a  logically  different  application  or  It  can  be 
combined  with  a  different  table  type  Into  a  table  which 
defines  a  new  relationship.  This  new  table  can  be  created 
for  an  ad  hoc  application  or  for  an  application  added  to  the 
IASS,  The  ability  to  combine  data  tables  lmoarts  to  the 
IASS,  caoabiiities  which  are  not  available  from  the  set  of 
disjoint  applications. 

8.   FOLLOW-ON  RESEARCH 

The  first  task  is  to  re-evaluate  the  logical  data  bases 
designed  for  the  IASS.  The  present  oroanization  implies 
that  each  aDDlication  Is  a  disjoint  database.  This 
persDectlve  was  useful  for  this  study,  but  It  Is  clear  that 
they  must  not  be  disjoint  if  it  implies  that  different  table 
types  cannot  be  combined.  Another  iteration  on  the  IASS 
tables   needs   to   be   done   to   combine    the    application 
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directories  and  data  table  schemas  Into  tables  in  a 
centrally  maintained  data  dictionary/directory. 

After  the  conceptual  level  is  re-evaluated,  the  next 
step  in  the  project  should  be  to  design  the  physical  level 
of  the  IASS  and  design  the  software  to  implement  the  system. 
It  is  recommended  that  the  first  iteration  of  the 
implementation  be  a  prototype  consisting  of  the  table  data 
object  and  the  ten  IASS  primitives,  to  evaluate  the  utility 
of  the  IASS  to  suoport  the  needs  of  a  user  in  ar\  actual 
operating  environment.  Subseguent  iterations  can  include 
the  DBMS  functions  such  as  data  integrity,  security,  and 
crash  recovery. 

Concurrent  with  the  Dhvsical  level  and  software  design, 
the  aDpiication  specific  command  languaaes  and  orocessing 
proarams  can  be  designed,  th^  text  formatter,  form  orinter, 
and  SDread  sheet  view  generator  can  all  be  designed  based  on 
the  data  table  definitions  and  the  anstract  interfaces  of 
the  primitives. 

Finally,  it  is  recommended  that  the  IASS  be  emulated  on 
an  existing  relational  DBMS  (e.g.  DBASE  II).  The  reason  for 
this  is  two-fold.  First  it  would  provide  an  available  test 
bed  which  can  be  used  to  test  concepts  which  need  to  be 
resolved  before  the  prototype  system  is  delivered.  Second, 
it  could  be  used  to  determine  the  manner  in  which  the  IASS 
will  handle  the  fundamental  needs  of   the   user   before   the 
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first  prototype  is  finished.  It  would  therefore,  be  a  way  to 
involve  the  user  in  the  early  design  staoes  of  the  IASS. 
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APPENDIX  A:  WORD  STAR 

WORD  STAR  is  a  word  processing  program  developed  by 
Micro-Pro  to  combine  tne  capabilities  of  a  screen  editor  and 
an  on-screen  text  formatter.  The  result  is  a  very  powerful 
text  editor  which  displays  the  referenced  file  as  it  will 
appear  on  the  printed  oage. 

WORD  STAR  is  primarily  menu-driven.  The  commands  which 
are  presently  valid  are  displayed  in  a  menu,  and  are 
executed  by  keystroke  combinations.  On-line  information  is 
available  to  the  user  concerning  many  other  aspects  of  /iQRD 
STAR.  The  menu  driven  feature  eases  user  initiation  to  WORD 
STAR  and  is  part  of  the  Help  facility.  The  level  of  help  is 
selectable  to  match  the  users  level  of  experience,  and 
determines  the  extent  to  *hich  the  menus  are  displayed  on 
the  CRT. 

word  STAR  is  composed  of  a  set  of  seven  hierarchically 
organized  menus  or  environments,  as  shown  in  Table  A.l.  The 
user  enters  *ORD  STAR  in  the  Mo-File  environment.  At  this 
point  there  is  no  file  in  reference,  the  oDject  granularity 
is  the  file,  and  the  menu  options  Include  commands  to: 
change  the  logged  disk  drive,  set  the  automatic  directory 
display  feature  (on/off),  set  the  help  level,  print  a  file, 
rename  a  file,  copy  a  file,  delete  a  file,  run  a  program, 
open  a  document  file,  and  open  a  non-document  file. 
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Table  A.l  -  WORD  STAR  Menu  Hierarchy. 


LEVEL 
"7" 

T" 


MENU 
No  File 
Main  Menu 


a.  Help 

b.  On-Screen  Format 

c.  Print  Control 

d.  QuicK  Edit 

e.  File/Biocx 


word  STAR  recognizes  two  tyoes  of  files,  "document"  and 
"non-document".  A  document  file  can  either  be  a  text  file 
processed  by  a  word  processor  or  a  proaram  run  oy  a 
comDuter,  A  non-document  file  is  a  special  ouroose  file 
which  is  used  by  another  software  product,  and  will  not  be 
discussed  further. 

The  on-screen  editor  and  formatter  are  invo<ed  by 
selectinq  the  menu  oDtion  to  open  a  document  file.  This 
causes  word  STAR  to  enter  the  lain  Menu  environment  with  a 
specific  file  in  reference.  If  the  file  oreviously  existed 
it  is  made  current,  otnerwise  a  new  file  is  created  and  made 
current.  On  entering  the  Main  Menu  environment,  a  status 
line  and  a  rule  are  Initialized.  The  status  Line  contains 
information  about  the  system  -  the  name  of  tne  file,  the 
page  within  the  file,  the  column  ang  row  number   the   cursor 
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is  at,  and  the  insertion  mode  (on/off).  The  rule  indicates 
the  right  and  left  margin  position  as  well  as  the  tab 
positions.  The  Main  Menu  represents  the  basic  file  editing 
environment  where  the  user  will  remain  until  it  is  decided 
to  guit  the  current  file  and  return  to  the  No  File  Menu  or 
the  oDerating  system.  In  any  case,  WORD  STAR  does  not 
permit  lateral  movement  between  the  sub-menus  of  the  Main 
Menu. 

A  useful  feature  word  STAR  emDioys  is  "word  wrap".  With 
word  wrap,  the  user  does  not  have  to  insert  carriage  returns 
at  the  end  of  each  line.  As  the  text  overruns  the  end  of 
the  line,  word  STAR  automatically  starts  tne  next  line.  In 
this  way,  the  user  merely  inouts  an  entire  bloc*  of  text  as 
a  continuous  ASCII  character  string,  and  leaves  the 
formattino  to  the  system.  In  the  Main  Menu,  the  user  can 
edit  tne  file  in  granularities  of  character,  word,  and  line. 
Insertion  is  a  "toggled"  operation  Con/off),  where  the  user 
is  either  in  insert  mode  or  overwrite  mode.  Any  Keystroxe 
entered  is  either  inserted  in  the  text  at  the  cursor 
position,  shifting  cnaracters  to  the  right  to  accommodate 
it,  or  overwrites  the  character  at  the  cursor  oosition.  To 
facilitate  on-screen  editina,  the  Main  *enu  contains 
commands  to  control  cursor  movement  and  to  scroll  the 
screen.  It  is  possible  to  insert  tabs  or  end-of-paragrapn 
markers.  There  is  a  "Find  and  Replace"  command  which  can  De 
repeated   any   numoer   of  times.   Deletions  can  be  done  on  a 
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single  character,  a  word,  or  an  entire  line.  The  Main  Menu 
also  contains  options  to  select  one  of  the  five  submenus. 

The  Quick  Editing  environment  supports  editing  on  higher 
levels  of  abstraction  of  text  objects  than  the  Main  Menu. 
There  are  additional  cursor  movement  commands  to  give  a 
wider  ranoe  of  control  and  granularity.  As  in  the  Main  Menu 
environment,  the  user  can  scroll  the  display,  but  now  it  is 
continuous  at  nine  user  selectaole  rates  until  stoooed  oy 
command.  Insertions  are  accomplished  in  tne  same  way  as  in 
the  Main  Menu  environment,  but  deletions  are  possible  on  a 
wider  range  of  objects.  There  is  a  feature  to  allow  a 
command  to  be  repeated  at  one  of  nine  user  selectaDle  rates, 
until  stopped  by  command. 

The  Block  environment  provides  the  user  a  set  of 
ocerations  on  a  block  of  text.  ■••ORD  STAR  considers  an 
entire  file  to  be  a  special  case  of  a  olock  of  text.  Files 
can  be  saved  by  several  menu  octions:  save  and  resume  the 
referenced  file,  save  and  guit  to  the  operating  system,  save 
and  exit  the  referenced  file,  and  copy  to  another  file. 
Files  may  also  be  renamed,  deleted,  printed,  or  quit  without 
saving  changes.  To  support  these  file  oDerations,  the  Block 
Menu  contains  options  to  change  the  loaged  disk,  and  to  turn 
the  automatic  directory  listing  on  or  off.  In  this 
capacity,  the  Block  environment  is  used  as  a  successor  to 
the  Main  or  Quick  Editing  environments  after  the  cursor  is 
positioned.   Blocks  in  a  file  must  be  marked   by   tne   user. 
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As  a  delimited  aggregation  of  text,  a  block  car  be  moved 
within  the  same  file.  Copying  blocks  of  text  can  either  be 
within  the  referenced  file  or  between  the  referenced  file 
and  an  external  file.  BlocK  copying  between  files  are  bi- 
directional. Copying  a  bloc*  to  an  external  file  entails 
overwriting  an  existing  file  or  creating  a  new  file. 
Copying  a  block  from  an  external  file  entails  moving  the 
entire  external  file  to  the  point  in  the  text  indicated  by 
the  cursor.  Any  marked  Dlock  can  also  be  deleted.  As  a 
precautionary  measure,  WORD  STAR  allows  the  user  to  hide 
block  markers,  and  only  blocks  which  are  vlsioly  marked  can 
be  deleted.  In  addition  to  a  text  block  being  organized 
into  a  continuous,  unstructured  string  of  text,  word  STAR 
supports  a  columnar  organization. 

The  previously  described  menus  contain  operations  to 
create,  edit,  position  the  cursor,  or  output  a  text  file. 
The  format  of  the  file,  either  as  it  is  visually  displayed 
or  printed  out,  is  defined  by  a  set  of  formatting  parameters 
associated  with  the  file  or  by  commands  embedded  in  the 
file.  The  formatting  parameters  associated  with  a  file  are 
initially  set  to  default  values  and  the  set  of  embedded 
commands  is  initially  empty. 

Formattina  in  WORD  STAR  is  primarily  done  on-screen  with 
the  options  contained  in  the  On-Screen  Menu.  The  on-screen 
formattina  commands  are  those  whose  effects  can  oe  visually 
displayed,  and  they  are  listed  in  Table  A. 2. 
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Table  A. 2  -  WORD  STAR  On-Screen  Formatting  Commands. 


1,  Set  left  margin 

2,  Set  right  margin 

3.  Release  margins 

4,  Set  and  clear  tabs 

5,  indent  a  paragrapn 

6.  Create  a  special  rule 

7.  Center  text 

8.  Set  line  spacing 


The  Qn-Screen  Menu  also  contains  options  in  the  form  of 
(On/Off)  toggles  to  control:  word  wrao,  rule  display, 
variable  tabbina,  hyphenation  help,  riaht  maraln 
justification,  soft  hyphen,  print  embedded  control 
characters,  and  page  brea<  disolay.  If  an  on-screen 
formatting  operation  needs  to  oe  applied  to  the  previous 
contents  of  the  file,  the  applicable  Dortlon  of  the  file 
must  be  reformatted.  Furthermore,  these  formatting 
parameters  are  only  temporarily  applied  when  the  file  is 
referenced.  Any  subseauent  reference  to  a  file  requires 
that  the  on-screen  formatting  parameters  be  reset. 

word  STAR  combines  into  one  menu,  the  Print  Menu,  all 
options  which  create  special  printing  effects  not  normally 
displayable  on  a  video  screen.  There  are  options  to:  bold 
face,  double  strike,  underline,  strike  out,  subscript,  and 
superscript.   Since  the  effects  of  these  octions   cannot   be 
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displayed  on  the  video  screen,  a  special  character  is  used 
to  marK  the  affected  area.  Additional  special  printing 
effects  are  selectable  through  this  menu  on  a  one  time 
basis:  overprint  a  character,  indicate  a  non-break  SDace, 
and  overprint  a  line.  The  Print  Menu  also  contains  options 
which  control  the  printer  durino  output.  The  user  may  embed 
commands  in  the  text  file  to  cause  the  printer  to  chanqe 
pitch,  or  cause  a  pause  to  allow  tne  user  to  change  the 
print  element  or  ribbon. 

Printing  can  also  be  directed  through  tne  use  of 
embedded  dot  commands.  These  commands  are  placed  in  the 
text  file  and  appear  as  regular  text  on  the  dismay,  but  are 
not  output  to  a  printer  and  force  WGRD  STAR  to  change  a 
printing  parameter  at  print  time.  Dot  commands  alter  the 
default  parameters  WORD  STAR  uses  to  format  the  printed 
page.   Table  A. 3  provides  a  listing  of  these  commands. 

Dot-commands  may  be  placed  anywhere  in  the  text,  but 
since  they  are  static  and  tend  to  destroy  the  relationship 
between  what  is  displayed  and  what  is  printed,  they  are 
usually  placed  at  the  beginning  of  the  text  file.  As  with 
the  options  of  the  Print  Menu,  dot-command  actions  must  be 
supported  by  tne  specific  printer  in  use. 

The  last  menu  to  be  described  is  the  help  Menu.  Help  is 
"on-line"  in  that  it  can  be  invoked  at  any  time  throuah  the 
Main  Menu,  and  is  "dynamic11  in  that  the  level  of  help  can  be 
adjusted.    The  level  *ill  determine  now  much  information  is 
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displayed  when  an  option  is  selected.  The  Help  Menu  options 
display  information  on:  paragraph  reforming,  flags  in  the 
right-hand  margin,  dot  and  print  commands,  status  line, 
ruler  line,  how  to  set  margins  and  taps,  and  how  to  move 
blocks  of  text. 


Table  A. 3  -  wOPD  STAR  Dot  Commands. 


1.  Set  line  height 

2.  Set  page  length 

3.  Set  top  margin 

4.  Set  bottom  margin 

5.  Generate  headers 

6.  Generate  footers 

7.  Set  footer  margin 

8.  Reset  page  numper 

9.  Offset  page  from  left  side  of  printer 

10.  Position  page  number 

11.  Set  character  width 

12.  Force  a  page  break 

13.  Prevent  a  cage  break 


word  STAR  is  an  excellent  and  very  ooDUlar  word 
processina  program.  The  screen-oriented  and  on-line 
formattina  features  are  different  from  other  systems  in  that 
they  are  extremely  easy  to  use.  Once  exoerience  is  qained 
with  WORO  STAR  It  is  difficult  to  use  line-oriented  editors 
or  off-line  formatting  systems.  The  on-line  nelD  facility 
makes  a/ORD  STAR  easy  to  learn  and  user  friendly.  One  aspect 
of   WORD  STAR  that  could  be  considered  a  disadvantace  is  the 


33 


larae  command  set.  However,  beino  menu-driven,  the  commands 
not  normally  used  do  not  have  to  be  memorized  since  they  are 
always  listed  in  the  menu. 
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APPENDIX  BJ  VI 

"VI"  Is  a  text  editor  used  by  the  UNIX  operating  system 
and  was  created  by  the  University  of  California  at  Berkeley, 
and  Bell  Laboratories. 

VI  (visual)  is  a  display  oriented  interactive  text 
editor  with  a  command  vocabulary  size  of  aoout  ninety  one. 
The  user  sees  the  CRT  screen  as  a  window  into  the  text  file 
and  all  editing  operations  are  immediately  visible.  Line 
numbers  are  not  displayed  and  hive  no  real  use  in  VI, 
although  it  is  possiole  to  find  out  the  number  for  a  line. 
For  the  sake  of  protection  the  user  does  not  actually  edit 
the  file,  DUt  a  copy  of  it.  At  the  completion  of  a  session 
the  user  will  indicate  whether  to  keep  the  edited  copy  or 
the  original. 

There  are  forty  seven  movement  commands  for  control  of 
the  cursor,  whicn  is  the  editor's  ooint  of  reference,  and 
the  screen  display.  Scope  of  movement  is  possible  over 
file,  screen,  oaragraoh,  section,  sentence,  line,  word,  and 
character  sized  units,  up  to  twenty  six  locations  in  the 
file  can  be  marked  for  later  return,  or  specific  locations 
found  that  match  a  desired  character  string.  Table  B.l 
lists  the  cursor  movement  commands  available  in  the  VI 
system.  Note  that  there  is  duplication,  in  that  more  than 
one  command  does  the  same  thing. 
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Table  B.l  -  VI  Cursor  Movement  Commands 


1.  Backward  window 

2.  Forward  window 

3.  Scroll  down  * 

4.  Scroll  up  * 

5.  Backspace  one  charact 

6.  Backspace  a  single  ch 

7.  Bac<up  a  word 

8.  Backup  a  word  during 

9.  Backup  to  beginning  c 

10.  Retreat  to  previous  1 

11.  Retreat  to  beginning 

12.  Retreat  to  beginning 

13.  Retreat  to  previous  s 

14.  Linefeed  advance  to  n 

15.  Advance  to  first  non- 
16.  Advance  to  next  line, 

17,  Advance  to  next  line, 

18,  Advance  to  next  chara 

19,  Advance  to  oeginning 

20,  Advance  to  end  of  nex 

21,  Advance  to  section  bo 

22,  Advance  to  the  next  t 

23,  Advance  to  beginning 

24,  Move  to  previous  line 

25,  Move  to  end  of  curren 

26,  Move  to  balancing  par 

27,  Moves  cursor  to  last 

28,  Moves  cursor  to  middl 

29,  Move  forward  to  begin 

30,  Move  forward  to  end  o 

31,  Move  to  first  non-whi 

32,  Move  to  line  number  # 

33,  Search  for  word  * 

34,  Search  forward  for  st 

35,  Search  backward  for  s 

36,  Search  for  next  match 

37,  Repeat  last  single  ch 

38,  Find  a  single  charact 

39,  Find  a  single  charact 

40,  Reverse  direction  of 


er  * 
aracter 

insert 

f  word 

ine  * 

of  sentence 

of  previous  paragraDh 

ection  boundary 

ext  line 

white  space  on  next  line  * 

first  white  space 

same  column  * 
cter  * 
of  word 
t  word 
undary 

yped  character 
of  next  DaragraDh 

t  line  * 

enthesis  or  orace 
line  on  screen  * 
e  of  screen  * 
nine  of  word 
f  word 

te  soace  on  current  line 
* 

ring  ** 
tring  * 
** 

aracter  search 
er,  backwards  * 
er,  forward  * 
Drevious  find 
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Table  B.l  -  (Cont.) 


41,  Find  first  instance  of  next  character 

42,  Repeat  the  last  search  command  * 

43,  Homes  the  cursor 

44,  Mar*  the  present  position  of  the  cursor  * 

45,  Return  to  marked  position  * 

46,  Redraw  the  screen 

47,  Returns  to  Drevious  context 


The  ooeratlons  of  insertion,  modification  and  deletion 
are  supported  by  thirty  commands  that  permit  the  user  a 
varied  level  of  object  control.  Items  that  are  Inserted, 
modified  or  deleted  are  immediately  updated  on  tne  screen  to 
give  tne  user  a  current  view  of  the  file  status.  The  user 
also  has  the  ability  to  undo  the  previous  command  if  its 
effects  were  undesired.  Most  insertion  and  modification 
commands  are  structured  so  that  they  continue  to  oDerate 
until  the  user  issues  a  command  to  terminate  tnem.  Normally 
during  insertion  the  user  has  control  of  format  in  tnat  new 
lines  are  started  by  entering  a  carriage  return.  However 
there  is  an  option  that  will  let  VI  determine  when  to  start 
a  new  line,  based  on  line  lengtn,  and  let  the  user  Just 
enter  text  as  a  continuous  stream.  Table  B.2  lists  the 
thirty  edit  commands. 

In  order  to  use  VI  the  user  issues  tne  command  "vi" 
followed   by  the  name  of  the  file  to  be  edited,  if  this  is  a 
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new  file,  then  the  name  will  not  be  found  in  the  directory 
and  VI  will  create  an  emoty  file.  After  entry,  the  user  will 
issue  cursor  motion  commands  to  maneuver  through  the  file, 
and  issue  edit  commands  to  change  the  contents  of  the  file. 
There  are  no  other  modes  or  displays  available  in  VI, 


Table  3,2  -  VI  Edit  Command  Summary 


1. 
2. 
3. 

4. 

5, 

6. 

7. 

8. 

9, 

10, 

11. 

12, 

13. 

14, 

15. 

16. 

17. 

18. 

19. 

20. 

21. 

22, 

23. 

24. 

25. 

26. 

27. 

29. 

29, 

30, 


Inse 
Inse 
Inse 
Inse 
Inse 
Inse 
Inse 
Inse 
Inse 
Inse 
Inse 
Dele 
Dele 
Dele 
Dele 
Dele 
Repe 
Join 
Red 
Reol 
Cnan 
Chan 
Chan 
Chan 
Undo 
Rest 
YanK 
YanK 
Repe 
Name 


rt  a 
rt  no 
rt  "s 
rt  at 
rt  at 
rt  be 
rt  af 
rt  ne 
rt  ne 
rt  te 
rt  te 
te  la 
te  re 
te  ch 
te  th 
te  si 
at  la 

toge 
ace  s 
ac€  c 
ge  th 
ge  si 
ge  th 
ge  re 

last 
ore  c 

foil 

a  co 
at  la 
d  buf 


number 
nprlnt 
hiftwi 
the  b 
end  o 
fore  t 
ter  th 
w  line 
w  line 
xt  bel 
xt  aoo 
st  cna 
st  of 
aracte 
e  foil 
ngle  c 
st  com 
ther  1 
ingle 
haract 
e  enti 
ngle  c 
e  foil 
st  of 

Chang 
urrent 
owing 
oy  of 
st  tex 
f er  sp 


of 
able 
dth" 
egin 
f  li 
he  c 
e  cu 

bel 

abo 
ow  c 
ve  c 
ract 
the 
r  oe 
owin 
hara 
mand 
ines 
char 
ers 
re  1 
hara 
owin 
the 
e  to 

lin 
obje 
curr 
t  in 
ecif 


spac 

cha 

bla 

ning 

ne 

urso 
rsor 
ow  c 
ve  c 
urre 
urre 
er 

text 
fore 
g  ob 
cter 
*  * 
* 
acte 
at  c 
ine 
cter 
g  ob 
text 
cur 
e  to 
ct  i 
ent 
sert 
icat 


es 

racters 
n<  spaces 
of  line 

r  ** 
** 

urrent  line 
urrent  line 
nt  line  ** 
nt  line  ** 

on  current  line  * 
cursor 
ject 
under  cursor  ** 


r  under  cursor 
ursor  ** 


ject 

on  current  line 
rent  ouffer  ** 

previous  condition 
nto  buffer  * 
line  into  ouffer 
ion 
ion  follows  * 
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In  addition  to  the  two  command  categories  already  given 
there  are  additional  commands  of  a  miscellaneous  nature. 
Table  3.3  lists  these  additional  commands. 


Table  B.3  -  Miscellaneous  VI  Commands. 


1.  Print  file  status  message 

2.  Clear  and  redra*  the  screen 

3.  Redraw  the  current  "logical"  screen 

4.  Suspend  or  restart  output 

5.  Cancel  Dartially  formed  command 

6.  Return  to  Dosition  in  last  edited  file 

7.  Reformat  lines  in  buffer 

8.  Indicate  file  and  ootion  manioulation 

9.  Quit  VI,  enter  line-oriented  editor 


Some  very  basic  formating  commands  for  line  length  and 
indenting  are  directly  available.  A  macro  creation 
capability  is  present  to  allow  tne  user  to  create 
abbreviations  for  command  strings.  Table  B,4  lists  these 
formatting  commands,  VI  makes  no  claim  to  suooorting  a 
formatting  package,  since  the  file  will  be  output  in  the 
same  format  the  user  entered  it.  For  special  formatted 
output  a  VI  generated  file  must  be  processed  by  an  off-line 
word  processor,  like  "*1R0FF  -ME"  described  in  Apoendix  CD). 

VI  provides  a  high  degree  of  support  to  the  user  for 
restructuring  a  file,  or  files.  There  are  nine  buffers 
available  for  storing  deleted  text,  and  twenty   six   Duffers 
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to  use  as  temporary  holding  spaces  while  reordering  and 
editing.  The  text  can  be  ta<en  from  other  files  and/or 
buffers,  for  use  in  the  file  currently  being  edited,  if 
needed,  previously  deleted  text  from  the  current  file  can  be 
recovered,  and  also  other  files. 


Table  B.4  -  VI  Formatting  Commands. 


1,  Reformatting  command 

2,  Shift  lines  left  one  "shiftwidth" 

3,  Reinden.t  lines 

4,  Shift  lines  right  one  "snif twidth" 

5,  Prints  current  file  contents 


WVIH  is  a  good  screen  oriented  editor  and  has  a  vide 
range  of  capabilities,  however  it  has  some  drawbacks, 

(1)  It  has  a  Doorly  designed  user  interface  since  the 
command  vocabulary  is  very  large  and  tne  individual  command 
strings  are  difficult  to  rememoer.  There  does  not  seem  to 
have  been  much  thought  given  to  the  design  of  the  command 
vocabulary. 

(2)  It  takes  a  fairlv  long  time  to  learn  the  VI  system 
and  gain  functional  use.  An  on-line  tutorial  program  is 
used  to  help  beainners,  since  it  is  hard  to  oecome  familiar 
with  it  on  their  own. 


90 


C3)  VI  does  not  inspire  user  confidence  in  that  it  is 
too  easy  to  accidentally  enter  some  unknown  command  string, 
and  tnere  is  little  correlation  between  what  the  user  wants 
to  do  and  the  commandCs)  that  must  be  issued. 

(4)  From  personal  use,  about  thirty  three  commands  were 
considered  to  be  generally  useful  (marked  by  *  or  **),  and 
only  ten  of  these  accounted  for  the  greater  majority  of  all 
operations  (mariced  by  **),  The  remaining  VI  commands  were 
generally  treated  as  "window  dressing"  Dy  all  but  the  most 
sophisticated  users. 

(5)  There  is  no  help  facility,  of  any  kind,  provided  by 
the  VI  system.  At  the  very  least,  an  on-line  listing  of 
commands  should  be  provided. 
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APPENDIX  C:  EDIT 

EDIT  is  a  text  editor  supported  by  the  UNIX  operating 
system,  EDIT  Is  a  simplified  version  of  another  UNIX 
editor  and  contains  a  minimal  set  of  operators.  It  is  line 
oriented  which  means  that  the  main  object  of  EDIT  is  a  line 
of  text  of  some  finite  lengtn, 

EDIT  merely  supports  text  file  creation  and  modification 
operations.  The  user  inputs  text  into  a  file  by  lines, 
indicating  the  end  of  a  line  by  a  carriaae  return,  A 
display  of  the  file  will  show  an  ordered  list  of  lines  as 
they  exist  in  the  file.  Ordering  of  lines  is  completely 
determined  Dy  the  system  and  although  the  user  can  use  line 
numbers  as  a  reference,  the  line  number  is  not  directly 
accessible  to  the  user  to  change  or  set.  *ny  display  of 
text  by  EDIT  is  done  by  line.  Substrings  can  be  referenced 
within  a  line,  or  lines,  A  formatted  output  disDlay  by  EDIT 
can  only  be  achieved  if  the  user  directly  inputs  the  desired 
format  line  oy  line,  no  processing  of  the  contents  of  a 
line  is  done  by  EDIT, 

when  Invoiced,  EDIT  sets  aside  a  temporary  copy  of  the 
referenced  file  in  a  working  buffer.  If  the  file  does  not 
already  exist  in  the  directory,  then  it  is  a  new  file  and  is 
created.  The  basic  set  of  commands  available  to  EDIT  are 
listed  in  Table  C.l. 
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Table  C.l  -  EDIT  Command  Summary. 


1.  Edit  a  file 

2.  Specify  a  file 

3.  Append  lineCs) 

4.  Insert  lineCs) 

5.  Insert  lineCs)  into  an  external  file 

6.  Insert  lineCs)  from  an  external  file 

7.  Delete  lineCs) 

8.  Copy  lineCs) 
5,  Move  lineCs) 

10,  Print  lineCs) 

11,  Show  line  number 

12,  List  lineCs) 

13,  Substitute  a  string 

14,  Search  for  string 

15,  Undo  last  command 

16,  Matce  effect  of  command  global 

17,  Move  cursor 

-  forward 

-  backward 

18,  Quit 


Searching  for  a  line  has  the  effect  of  maklna  the  found 
line  the  current  line.  Any  subsequent  editina  ooerations 
are  done  in  relation  to  the  current  line.  Lines  can  be 
found  and  displayed  by  line  numbers,  and  ranges  of  lines  can 
be  specified.  Lines  can  also  be  found  and  displayed  forward 
or  backward,  relative  to  the  current  line,  A  line  can  be 
found  by  any  substring  of  its  contents,  but  the  entire 
substring  must  be  contained  in  one  line.  Because  of  this 
deficiency  a  substring  may  not  be  locatable  merely  Decause 
it   exists   in  the  text  file,   when  searchina  EDIT  will  move 
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forward  or  backward  and  will  wrap  around  the  buffer,  so  as 
to  return  to  the  starting  line  if  tne  target  object  is  not 
found. 

New  lines  can  be  appended  before  the  current  line,  or 
inserted  after  it.  The  user  issues  a  command  to  specify  that 
there  are  no  more  lines  to  add.  Upon  completion  the  current 
line  is  the  last  line  added.  Additions  can  also  be  made  by 
moving  or  copying  lines  within  the  text  file.  Moving  can  oe 
viewed  as  a  combination  of  a  deletion  and  an  insertion.  3y 
specifying  a  range  of  lines  to  be  changed,  they  are  deleted 
and  the  system  enters  insert  mode  for  the  user  to  add  tne 
new  lines.  Additionally,  insertions  are  possible  from  other 
text  files. 

Modifying  a  line  is  done  by  substitutino  a  new  string 
for  an  already  existing  target  string  on  the  line.  If 
desired,  the  substitution  can  have  global  effect  in  tnat  it 
will  modify  all  occurrences  of  the  target  string  on  all 
lines. 

Deletion  is  usually  accomplished  by  Indicating  the  line, 
or  lines,  to  be  deleted.  A  search  command  can  oe  used  with 
the  deletion  operation  when  the  specific  line  numbers  are 
not  know. 

EDIT  Drotects  the  user  from  making  inadvertent  chanaes 
to  a  text  file.  The  effects  of  the  last  executed  command 
that  effected  the  buffer  can  be  reversed.  Additionally,  the 
effects   of   the   editing   session   do   not  oecome  Dermanent 
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unless  the  user  issues  a  command  to  make  them  permanent.  At 
that  point  the  edited  copy,  which  is  in  the  buffer,  reolaces 
the  original  file  in  the  directory.  Leaving  EDIT  without 
indicating  to  maice  the  changes  permanent  is  like  the  editing 
session  never  occurred. 

In  addition  to  writing  a  whole  buffer  out  to  the 
directory,  subparts  can  be  written  to  another  text  file. 
This  is  done  by  specifying  tne  range  of  lines  and  tne  file 
to  be  written  to. 

The  EDIT  text  editor  is  very  basic  which  is  both  an 
advantage  and  a  disadvantage.  It  has  a  minimal  command  set 
and  therefore  is  easy  to  learn.  The  bigaest  problem  is  that 
it  is  line-orientea.  As  such,  modifications  are  done  a  line 
at  a  time,  where  eacn  line  is  a  separate  entity,  it  does  not 
treat  the  tile  as  a  whole,  but  as  a  disjoint  collection  of 
lines.  It  imposes  the  idea  of  line  numbers,  wnich  do  not 
exist  in  tne  text  file,  in  order  to  use  the  editor.  There 
are  fewer  high  level  editing  operations  available,  as 
comDared  to  current  screen-oriented  editors,  and  they  are 
limited  to  operating  on  lines  and  not  tne  text  file  as  a 
whole.  *hile  capaole  of  producing  satisfactory  results,  due 
to  its  line  at  a  time  limits,  the  operation  oecomes  tedious 
if  the  file  is  large,  and/or  there  are  a  lot  of  small 
chanaes  which  must  be  done.  Given  the  advanced  features  of 
todays  line-oriented  editors,  EDIT  is  a  very  archaic  and 
frustratina  way  to  create  and  modify  a  text  file. 
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APPENDIX  D:  NROFF  -ME 

"NROFF  -ME"  is  a  text  processing  facility  for  files  that 
are  created  on  the  UNIX  operating  system.  It  was  created  by 
the  University  of  California  at  Berkeley,  and  Bell 
Laboratories,  "NROFF"  is  a  program  that  acceots  an  incut 
file  prepared  bv  tne  user  and  outputs  a  formatted  caper  to 
the  user's  design,  "-me"  is  a  macro  package  that  enhances 
the  capabilities  of  the  "NROFF"  program  oy  addirq  additional 
formatting  abilities  and  commands.  The  input  file  consists 
of  the  actual  text  entered  by  the  user,  through  some  editor 
system,  and  a  series  of  embedded  NROFF  -ME  commands. 

There  is  a  large  vocabulary  of  "reauests",  which  are 
really  dot-commands  consisting  of  a  period  followed  by  a  two 
letter  string.  The  basic  NROFF  package  supDorts  seventeen 
categories  of  commands,  and  has  a  total  of  eighty  seven 
commands.  The  -ME  package  adds  three  categories  and  a  total 
of  sixty  commands  for  a  grand  total  cf  one  hundred  and  forty 
seven  commands.  Table  D.l  lists  the  NROFF  and  -ME  command 
categories,  and  the  number  of  commands  in  each, 

NROFF  -WE  uses  thirteen  predefined  general  variables  and 
twenty  three  predefined  read-only  variables  to  support  its 
processina  needs.  The  user  is  provided  with  a  macro 
facility  to  define  new  commands  in  terms  of  the  basic  set  of 
commands  and  operations  on  the  variables.   This   allows   the 
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user   to   abbreviate   a   fairly   long   command  stream  into  a 
single  command. 


Table  D,l  -  NROFF  and  -me  Commands. 


COMMANDS 


COMMAND  CATEGORY 


*ROFF 


-ME 


1, 

Font 

2, 

Paae 

3. 

Text 

4. 

Disp 

5. 

Vert 

6. 

Line 

7. 

Para 

8. 

Macr 

9. 

Numb 

10. 

Tabs 

11. 

Inou 

12. 

Hyon 

13. 

Titl 

14. 

Head 

15. 

Line 

16. 

Cond 

17. 

Envi 

18. 

Stan 

19. 

Inpu 

20. 

Misc 

&  Character  Size  Control 

Control 

Filling,  Adjusting  &  Centerina 
lays 
ical  spacing 

Length  &  Indenting 
oraphing 

os,  Strings,  Diversions,  &  Traps 
er  Registers 
,  Leaders,  &  Fields 
tOutDut  Conventions 
enation 
es 
inos 

Numbering 
ltional  Input 
ronment  Switching 
dard  Input  Insertions 
tOutout  File  Switching 
ellaneous 


7 

9 

7 

0 

6 

0 

0 

22 

7 

0 

3 

0 

0 

4 

t3 

0 

3 

0 

4 

0 

9 

0 

4 

0 

3 

13 

0 

b 

2 

0 

8 

0 

1 

0 

2 

0 

3 

0 

5 

6 

TOTAL 
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60 


NROFF  -ME  is  a  good  word  processing  system  and  it  can 
produce  some  complex  formatting  actions.  However,  it  does 
suffer  from  some  drawbacks, 

(1)  Since  the  file  is  first  created  by  the  text  editor 
and   then   run  by  NROFF,  the  user  has  a  significant  delay  in 
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determining  if  the  desired  format  was  achieved. 

(2)  In  addition  to  depending  on  the  text  editor,  NROFF 
must  depend  on  other  programs  to  preprocess  the  text  file 
before  NROFF  can  handle  it  for  specialized  reauests.  Two 
examples  of  preprocessors  are  packages  to  handle  tables  and 
complex  eguation  symbology.  *hile  enhancing  MROFF  -ME's 
capabilities,  they  add  more  categories  and  commands,  and 
increase  the  amount  of  time  necessary  for  the  user  to  see 
the  actual  results  of  commands. 

(3)  The  user  manual  for  the  NROFF  packaae  is  not 
presented  in  sufficient  detail  to  completely  understand  the 
effect,  or  use,  of  all  commands.  It  appears  that  the  user 
is  supposed  to  have  a  basic  understanding  of  the  system 
before  reading  the  manuals! 

(4)  The  command  vocabulary  is  fairly  large  anri  they  are 
not  easy  to  remember.  Based  on  oersonal  use,  only  about 
twenty  percent  of  the  vocabulary  is  generally  useful  and 
therefore  remembered.  Table  D.2  oresents  a  simoiified 
listing  of  the  most  used  commands. 
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Table  D.2  -  Basic  Commands  NROFF  -ME 


1.  Pace  length 

2.  Llr.e  spacing 

3.  Line  lengtn 

4.  Page  headers 

5.  Indent 

-  permanent 

-  temporary 

6.  Begin  next  page 

7.  Need  t  lines 

8.  Insert  #  blank  lines 

9.  Center  tne  next  *  lines 

10.  Break 

11.  Define  a  macro 

12.  Fiil/No-fill 

13.  Hyphenate/No-hyphenate 

14.  Underline 

15.  Section/Chapter  headings 

16.  Quotations 

17.  Footnotes 

18.  Keep  an  index 

19.  Start  paragraph 

-  basic 

-  left  adjusted 

-  body  indented 

-  numbered 

20.  Start   display 

-  list 

-  dock 

-  floating  block 

-  delayed  text 

21.  Table  handler  * 

-  definition 

-  start 

-  body 

-  end 

22.  Eauation  definition 

23.  Multiple  column  format 

24.  Default  paoer  formats 

-  thesis 

25.  Control  constructs 

-  read  sDecial  variables 

-  change  special  register 

-  conditional  formatting 

*  Dart  of  Table  preprocessor 
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APPENDIX  E:  DBASE  II 

DBASE  II  is  a  relational  database  system  created  by 
Ashton-Tate  of  Los  Angeles,  California  for  microcomputer 
systems.  For  this  review,  the  CP/M  version  of  DBASE  II  was 
used,  wnere  the  DBASE  II  program  is  an  executable  "command 
file"  residing  in  the  system. 

The  DBASE  II  system  utilizes  several  different  file 
types:  database,  report  form,  command,  index,  memory,  and 
text.  Each  file  type  has  a  specific  purpose  that  is 
identifiable  by  its  type  name.  "Report  form"  files  store  the 
information,  specified  by  the  user,  for  describing  the 
format  (headings,  fields,  totals,  subtotals,  contents,  etc.) 
in  which  a  "database"  file  is  to  be  output.  "Command"  files 
contain  a  seguence  of  DBASE  II  statements,  commands,  and 
control  structures  necessary  to  create  a  user  defined  view. 
"Index"  files  are  a  list  of  pointers  to  a  specific 
"database"  file.  "Memory"  files  contain  tne  values  of 
memory  variables  and  constants  saved  previously  bv  the  user. 
"Text"  files  are  collections  of  ASCII  characters  for  input 
into  a  "database"  file,  or  created  by  output  from  a 
"database"  file.  DBASE  II  cannot  directly  use  "text"  files. 
Most  of  the  files  are  stored  in  what  is  known  as  Standard 
Data  Format  CSDFD,  and  they  can  be  used  directly  by  any 
other   program   that  uses  SDF  files.   Additionally,  any  text 
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files  In  SDF  can  be  used  by  the  DBASE  II  system.  The  file 
Is  the  largest  data  object  supported  by  DBASE  II  which 
creates,  deletes,  or  modifies  the  current  file(s).  A 
database  file  is  brought  into  reference  by  user 
specification,  and  a  maximum  of  two  database  files  can  be 
"open"  at  one  time. 

DBASE  II  can  be  used  interactively  or  can  be  Drogrammed 
to  create  a  view  of  the  database  to  supDort  recurring 
applications.  Regardless  of  method,  DBASE  II  oroviaes  the 
user  with  the  same  basic  high-level  data  definition  (DDL) 
and  data  manipulation  (DML)  language.  An  English  lifce 
command  language  with  a  very  regular  syntax  is  a  user 
friendly  feature  of  DBASE  II,  Tne  commands  are  very 
powerful  in  that  their  operands  and  results  are  typically 
database  files.  The  command  structure  is  usually  presented 
in  the  following  form: 

COMMAND  CSC0PE3  [CONDITION] 

The  scope  modifier  designates  the  number  of  records  to 
be  selected  in  response  to  the  specific  command.  The 
condition  modifier  specifies  a  conditional  statement  that 
the  record's  field  values  must  satisfy  in  order  for  the 
record  to  be  included  in  the  final  result.  Table  E.l 
provides  a  listing  of  the  basic  DBASE  II  commands,  with 
duplicate  commands  having  been  factored  out. 
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Taole  E.l  -  DBASE  II  Basic  Commands. 


1. 
2. 
3. 
4. 
5. 
6. 
7. 
8. 
9. 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 


Dlspla 
Format 
Input 
Input 
wait  £ 
List  t 
Dlsola 
Dlsola 

Erase 

Genera 

Execut 

Return 

Dlsola 

Store 

Save  m 

Restor 

Select 

Set  sp 

Abort 


y  an 
scr 

a  ch 
a  st 
or  u 
he  r 
y  da 
y  th 

a  £ 
a  fi 
te  a 
e  a 

fro 
y  th 
a  va 
emor 
e  me 

a  s 
ecif 
a  co 


expr 

een  o 
aract 
ring 
ser  i 
ecord 
ta  fr 
e  str 
lie 
le 

repo 
"comm 
m  a  H 
e  con 
lue  i 
y  var 
mory 
pecif 
ic  DB 
mmand 


ession  on  the  screen 

r  printer  output 

er  strino 

to  a  memory  variable 
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command"  file 

tents  of  the  memory  variables 

n  a  memory  variaoie 
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variables  from  a  file 

ic  dataoase  for  use 

ASE  II  parameters 


21.  Create  a  new  database 

22.  Edit  a  database 

23.  Modify  a  database's  structure,  or  the 

contents  of  fields  in  selected  records 

24.  UDdate  a  database  from  another  database 

25.  Add  data  from  a  text  file  to  a  database 

26.  Copy  data  from  a  database  to  a  text  file 

27.  Insert  recordCs)  into  a  database 

28.  Delete  recordCs)  from  a  database 

29.  Unmark  records  marked  for  deletion 

30.  Locate  a  record  based  on  Key  value, 

or  condition 

31.  Goto  a  specified  record 

32.  Move  forward  or  backward  in  a  database 

33.  Index  a  database 

34.  Sort  a  database  based  on  a  field 

35.  Perform  JOIN  operation  on  two  databases 

36.  Count  the  number  of  records 

37.  Sum  a  field  or  subfield  in  a  database 
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Default  ordering  for  records  in  a  database  file  is  the 
sequence  in  which  the  records  are  entered.  Ordering  can  be 
altered  by  inserting  records  into  specific  parts  of  the 
database,  and  by  sorting  or  indexing  the  database.  In  the 
default  order,  the  "database"  file  does  not  contain  a 
recognized  key. 

By  sorting  or  indexing  a  "database"  file,  keys  are 
defined  and  the  search  time  required  to  locate  a  record  is 
reduced.  Multiple  indexing  be  done  for  the  same  database, 
but  base,d  on  different  keys.  Sorting  produces  a  new 
"database"  file,  which  is  a  copy  of  the  original  dataoase, 
only  it  is  sorted.  An  "indexed"  file  is  a  virtual  file  of 
oointers  to  the  original  "database"  file.  Whereas  lookup 
speed  can  be  enhanced  by  indexing  a  database,  there  is 
overhead  incurred  in  maintenance  of  the  "index"  fil-e. 
Changes  made  to  the  original  database  file  are  not  reflected 
in  the  new  sorted  "database"  or  "index"  file.  The  oriolnal 
database  must  be  sorted  or  indexed  after  each  change  in 
order  to  remain  current. 

The  data  definition  language  allows  tne  user  to  define 
the  oraanization  of  the  data  in  a  new  database  file  oy 
specifying  the  name  of  the  database,  and  giving  information 
on  each  of  its  fields  (name,  type,  width,  decimal  places). 
The  structure  of  a  new  database  file  can  also  oe  copied  from 
that  of  another  database  file.  Additionally,  new  structures 
can  be  created  as  the  result   of   using   the  JOIN   operator 
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provided  by  the  DBASE  II  system.  At  any  time,  the  structure 
and/or  contents  of  a  file  can  be  displayed  or  output.  The 
structure  of  a  database  file  can  also  be  modified  at  a  later 
time,  but  presents  some  problems  in  that  all  records 
currently  in  the  database  file  are  destroyed. 

Besides  using  DBASE  II  interactively,  it  can  be 
programmed  in  its  own  language  through  the  use  of.  "command" 
files.  Trie  DML  statements  are  embedded  in  the  file  and 
iterative  execution  of  DML  statements  are  controlled  by  a 
set  of  DBASE  II  control  structures  Clf-Then,  If-Then-Else, 
Goto,  and  Do-wnile).  "Command"  files  tend  to  make  extensive 
use  of  memory  variables  and  input/output  functions  which  are 
also  extensively  supported  by  DBASE  II.  To  create  a  user 
view  the  deslgner/proarammer  will  edit  a  "command"  file(s) 
to  contain  the  correct  DBASE  II  statements,  commanas,  and 
control  structures  to  manipulate  the  oroper  "database" 
files.  The  capabilities  and  limitations  of  any  view  is 
dependent  on  the  design  of  tne  "command"  tile(s). 

The  reason  for  the  great  popularity  of  DBASE  II  is  that 
it  is  a  very  easy  database  management  system  to  learn  and 
use.  Its  English-like  command  language  is  natural  and  user 
friendly.  Although  the  command  set  is  rather  extensive,  the 
command  names  accurately  describe  their  action  and  use  a 
regular  syntax  so  they  are  easy  to  rememoer.  The 
interactive  nature  and  full  screen  display  orientation  makes 
user   interaction   simple   and   direct.    With   its   set   of 
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predefined  functions,  input/output  commands,  "command11 
files,  and  programming  constructs  it  is  easy  to  create  views 
for  almost  any  application,  DBASE  II  is  a  powerful 
relational  database  system  yet  it  is  obvious  tnat  the 
designers  gave  much  thought  to  Keeping  it  simple  and  did  not 
introduce  complexity  for  its  own  saKe.  However,  there  are  a 
couple  of  problems  wltn  DBASE  II  which  are  worth  mentioning, 
and  they  are  all  probaoly  due  to  the  justified  emphasis  on 
simplicity, 

(1)  At  any  one  time,  a  maximum  of  two  databases  can  t>e 
in  reference.  This  limitation  reguires  that  databases  be 
explicitly  brought  into  and  out  of  use.  It  would  help  if 
there  was  another  method,  besides  using  a  "command"  file, 
for  performing  operations  on  multiple  taoles. 

(2)  In  modifying  the  structure  of  a  database  the 
contents  are  deleted.  This  reauires  that  the  database  oe 
explicitly  saved  to  an  external  database  and  then  oe 
recopied  back  after  structure  modification.  It  is  an 
inconvenience,  to  say  the  least. 

(3)  The  only  relational  operation  directly  provided  by 
the  system  is  the  JOIN  command.  It  would  greatly  enhance  the 
capability  of  the  system  to  provide  more  of  the  operators. 

(4)  The  display  structure  is  a  little  bit  too  rigid, 
and  the  user  does  not  have  much  direct  control,  sort  of 
writing  a  "command"  file,  to  effect  the  output  format. 
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APPENDIX  F:  SEQUITUR 

SEQUITUR  is  a  relational  database  system  designed  by  the 
Pacific  Software  Manufacturing  Company  of  Berkeley, 
California. 

SEQUITUR  sees  a  database  as  a  collection  of  named 
tables,  each  of  which  contains  some  kind  of  data  related  to 
the  subject  of  the  database.  Each  dataoase  has  a  set  of 
system  tables.  The  "Column"  table  lists  the  name,  tyoe, 
size,  and  display  format  of  all  columns  authorized  for  use 
in  the  database's  tables.  The  "Table"  table  lists  the  names 
of  the  columns  that  are  included  in  each  of  the  database's 
tables.  Together  the  "Column"  and  "Table"  tables  act  as 
part  of  a  data  dictionary  system  for  the  database. 

SEQUITUR  has  a  fairly  large  command  vocabulary  of  over 
sixty  seven  commands.  There  are  twenty  five  basic  commands, 
forty  two  screen  editor  commands,  and  more  formed  by 
compinations  of  the  previous  commands.  A  multilevel  "Helo" 
facility  is  used  to  support  the  user. 

SEQUITUR  offers  four  Kinds  of  help.  There  are  status 
lines  at  tne  toe  of  the  screen.  An  "edit  card"  display  can 
be  called  py  the  user  in  order  to  see  a  comprehensive  list 
of  cursor  object  and  motion  <eys,  and  escape  operations. 
The  "help"  command  summons  an  on-line  manual,  that  is  Dreset 
py  the  user  to  provide  no,  medium,  or  maximum  help.   Lastly, 
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there  are  situational  help  prompts   that   occur   during   the 
command  process. 


Table  F.l  -  SEQUITUR  Basic  Commands 


1.  CHOCSE  {database) 

2.  CREATE  {database) 

3.  ADD  to  {table) 

4.  EDIT  {table) 

5.  SHOW  {table) 

6.  PPINT  {table} 

7.  REPORT  generator 

8.  FORMS  generator 

9.  SELECT  from  {table)  * 

10.  MANUAL  select 

11.  JOIN  {tables) 

12.  SORT  {tables)  * 

13.  UNION  * 

14.  INTERSECTION  * 

15.  DIFFERENCE  * 

16.  UNIQUE  rows  * 

17.  DUPLICATE  rows  * 

18.  COPY 

19.  APPEND 

20.  REMOVE  rows 

21.  rename  column 

22.  COMPACT  base 

23.  DUMP  to  {file) 

24.  LOAD  from  {file} 

25.  HELP  from  manual 

26.  EXIT 


s   Member  of  SEQUITUR's  "set"  commands. 


The  twenty  five  basic  commands  cover  the  major 
operational  capabilities  of  the  SEQUITUR  system.  The 
commands  are  presented  to  the  user  in  tne  form   of   a   menu, 
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and  once  a  choice  is  made  SEQUITUR  enters  the  display  mode 
necessary  to  support  that  choice.  Table  F.l  lists  the  basic 
commands,  plus  the  command  for  exiting  from  SEQUITUR, 

The  SEQUITUR  display  modes  are  organized  as  "tables",  or 
"pages",  The  table  mode  is  similar  to  the  approach  taken  by 
the  "Query-by-Example"  system  (QBE),  and  presents  the  data 
in  columns  and  rows  with  vertical  lines  separatina  the 
columns  and  indicators  for  new  rovs.  Alternatively,  the 
page  mode  presents  the  data  one  row  at  a  time,  with  the 
column  headings  listed  vertically.  The  user  has  the  ability 
to  flip  back  and  forth  between  the  two  display  modes  at 
will. 


Table  F.2  -  SEQUITUR  Cursor  Object  &  Motion  Commands. 


1,  Move  cursor  up  one  line 

2,  Move  cursor  down  one  line 

3,  Move  cursor  left  one  object 

4,  Move  cursor  to  next  object 

5,  Move  cursor  to  beainning  of  object 

6,  Move  cursor  to  previous  word 

7,  Move  cursor  to  end  of  current  object 
9,  Move  cursor  to  next  word 

9,  Object  =  word 

10,  Object  =  line 

11,  Object  =  sentence 

12,  Object  =  Daragraph 

13,  Object  s  view 

14,  Object  =  paoe  or  screen 

15,  Object  =  column 

16,  Object  =  row 

17,  Object  =  one  cnaracter 
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Once  in  a  desired  display  mode  the  user  must  make  use  of 
the  editor  commands  to  make  changes  to  the  table.  All  editor 
commands  are  single  '  keys  combined  with  the  <Control>, 
<Escape>,  or  <Tab>  keys.  Table  F.2  provides  a  list  of  the 
cursor  object  and  motion  commands  available.  Most 
operations  reguire  t*o  commands  since  the  object  must  be 
specified  first,  and  then  the  actual  oDeration. 


Tade  F.3  -  SEQUITUR  Screen  Editor  Commands. 


1.  Delete  left  portion  of  object 

2.  Delete  entire  object 

3.  Delete  right  oortion  of  object 

4.  Flips  "insert"  toggle 

5.  Shows  rows  marked  for  deletion 

6.  Flip  "page-taole"  display  style 

7.  Goto  «-th  object 

8.  Goto  last  ooject 

9.  Restores  more  recent  version  of  row 

10.  Display  earlier  version  of  row 

11.  Executes  a  command 

12.  Search  forward  for  column  entry 

13.  Search  backwards  for  column  entry 

14.  Edit  card  disolay 


The  screen  editor  commands  are  used  to  make  actual 
changes  (additions,  modifications,  or  deletions)  to  the 
displayed  table  on  the  screen.  Table  F.3  lists  these 
commands  wnicn  are  used  in  conjunction  with  the  cursor 
object  and  movement  commands  listed  previously. 
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Additionally   there   are   a   number   of    miscellaneous 
commands  that  are  provided  to  aid  the  user.  These  are  listed 

# 

in  Table  F.4. 


Table  F.4  -  Additional  SEQUITUR  Commands 


1.  Get  Edit  Help 

2.  Scroll  Forward 

3.  Scroll  8ac<wards 

4.  Interrupt  Present  ODeration 

5.  LocK/Unlocfc  Cursor  Object 


There  are  an  abundance  of  table  tyoes  in  SEQUITUR. 
"Virtual"  tables  consist  of  oointers  to  data  in  a  "base" 
table(s),  and  are  formed  by  conducting  relational  operations 
Ce.o.  JOIN)  on  the  base  table(s).  Virtual  taoles  are 
permanent  additions  to  the  database.  All  operations 
conducted  on  the  virtual  table  effect  the  base  table,  but 
not  all  operations  on  the  base  table  will  reflected  in  the 
virtual  table. 

"Slice"  tables  consist  of  the  data  from  a  "home"  table, 
and  are  formed  by  restricting  or  rearranging  the  columns  in 
the  home  table.  Actually,  slice  tables  are  just  alternate 
ways  of  viewing  the  same  nome  table.  All  operations 
conducted  on  the  slice  table  effect  tne  home  table,  and  all 
operations  on  the  home  taole  effect  the  slice  table. 
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"Template"  tables  are  used  to  store  control  information 
on  the  ooeration(s)  (SELECT,  SORT,  UNION,  DUPLICATE,  UNIQUE, 
INTERSECTION,  and  DIFFERENCE)  desired  to  be  performed  on  a 
set  of  "base"  tables.  The  user  specifies  once  the  seauence 
of  operations  to  be  performed,  and  each  time  that  result  is 
desired  the  appropriate  template  table  is  called  to  create 
the  desired  virtual  table. 

SEQUITUR  provides  several  methods  of  outDutting  data  to 
the  user: 

(1)  There  is  the  "print"  command  which  promots  the  user 
to  specify  heading,  page  length,  margins,  page  numper,  date, 
column/row  divider  symbol,  etc,  for  either  a  "table"  or 
"page"  style  output.  The  entire  table  is  then  output,  one 
record  at  a  time,  in  the  specified  format. 

(23  There  is  the  "form  Generator".  The  user  creates  a 
form  letter  or  document  by  making  an  entry  in  the  "forms" 
table  in  either  "page"  or  "taole"  style,  and  answering 
several  system  prompts  as  to  page  size,  width,  margins.  The 
form  generator  is  intended  for  letter  tyoe  generation  since 
it  only  allows  one  text  field  in  the  form.  All  other  entries 
are  pulled  from  an  aDpropriate  table  and  the  "form"  reoeated 
for  each  row  in  that  table. 

(3)  There  is  the  "report  generator".  The  user  creates  a 
report  table  that  is  associated  with  a  Known  data  table.  The 
report  table  specifies  wnich  data  table  columns  are  to  be 
used,   how   they   are  positioned,  what  name  tney  nave  on  the 
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form,  allotted  width,  and  alignment.  Again,  the  user  must 
specify  formatting  items  like  page  length,  line  length, 
marains,  delimiters,  and  other  related  items.  The  individual 
columns  in  the  report  taoie  can  be  marked  for  sorting, 
grouping,  and/or  arithmetic  processing.  If  arithmetic 
processing  is  opted  for,  then  another  tade,  the  "function" 
table  is  created  to  record  wnat  is  to  be  done  to  each  column 
-  total,  minimum,  maximum,  average,  or  count. 

Based  on  a  very  short  familiarization  exoerience  with 
SEQUITUP  there  is  no  doubt  that  it  is  a  powerful  and 
complete  relational  DBMS.  However,  it  is  not  as  user 
friendly  as  its  advertisements  would  lead  you  to  believe. 
Some  of  the  problems  encountered  were: 

CI)  Too  many  commands  to  remember.  This  increased 
learning  time  and  added  to  the  confusion.  Too  many  of  tne 
commands  were  just  window  dressing  in  that  tneir  effect 
could  have  oe  done  using  other  commands.  (Like  the  "Object 
s",  extra  cursor  iTiovement  and  deletion  commands.)  while 
using  keys  as  commands  leads  to  faster  command  input,  it 
makes  things  more  difficult  when  tnere  are  so  many  commands 
the  symbol  on  the  key  has  little  or  no  relation  to  its 
effect. 

(2)  The  structure  of  the  user  interface  was  unwieldy.  It 
was  easy  to  get  lost  and  difficult  to  recover  to  a  known 
location.   Operations  that  worked  under   one   condition   aid 
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not  worx  In  another,  or  produced  completely  different  and 
unexpected  results.  (e.g.  in  some  instances  the  "execute" 
command  will  return  you  to  the  main  menu,  in  others  it  was 
ignored  or  treated  as  a  mistake,) 

(3)  There  were  too  many  types  of  tables,  ways  of  using 
tables,  editing  tables,  and  creating  relations  between 
tables.  The  user  is  being  swamped  with  a  level  of  detail 
that  is  oetter  left  to  the  system.  It  seems  that  SEQUITUR 
was  created  with  simplicity  and  user  support  belnq  lesser 
considerations  to  system  sophistication. 
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APPENDIX  G:  VISICALC 

VISICALC  is  an  electronic  spreadsheet  program  created  by 
Software  Arts,  Inc.  of  Cambridge,  Massachusetts  and  marketed 
by  Personal  Software  Inc.  of  Sunnyvale,  CA,  Its  purpose  is 
to  allow  the  user  to  easily  model  a  wide  range  of  numerical 
proolems  in  a  standard  tabular  format  by  replacing  the 
user's  pencil,  calculator,  and  scratchpad. 

The  screen  is  divided  into  a  grid  of  columns  and  rows 
that  form  addressable  (column,  row)  entry  positions.  The 
columns,  which  run  across  the  too  of  the  grid,  are  lettered 
starting  with  "A"  and  the  rows,  which  run  down  the  side,  are 
numbered  starting  with  " 1 " ,  Each  entry  position  is  an 
independent  entity,  and  can  contain  a  character  strinq,  a 
numeric  value,  or  a  function  that  must  oe  calculated.  Entry 
positions  that  contain  functions  are  recalculated  by 
VISICALC  each  time  certain  conditions  are  met.  The  functions 
will  specify  values  in  terms  of  constants,  operators,  and 
the  values  of  other  entry  positions. 

The  screen  is  used  as  a  "window"  into  the  spreadsheet 
and  is  modifiable  by  the  user.  The  user  is  given  numerous 
commands,  see  Table  G.l,  with  which  to  alter  the  disolay 
format  of  the  screen. 
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Table  G.l  -  VISICALC  Display  Commands. 


1. 
2. 


3. 
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The  window  can  be  "split"  into  two  halves  so  as  to  loo< 
into  nonadjoining  areas  of  the  spread-sheet  simultaneously. 
The  two  windows  can  be  "synchronized"  so  they  move  tooetner, 
or  unsynchronized  so  movement  is  indeoendent.  Disolay 
format  may  be  globally  set  for  the  screen  as  a  whole,  or 
individual  entry  Dositions  can  be  assigned  their  own  format. 
Column  width  is  variable  from  3  to  37,  out   columns   in   the 
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same  window  must  have  the  same  width.  The  value  of  each 
entry  Dosition  is  calculated  by  "column  order"  (Al,  A2,  ..., 
An,  81,  32,  ,..,  Bn,  CI,  etc.)  unless  the  user  chanoes  the 
recalculation  order  to  "row  order"  (Al,  81,  ...,  nl,  A2,  B2, 
...,  n2,  C2,  etc.).  By  default  VISICALC  starts  in 
"automatic"  recalculation  mode  where  the  value  of  all  entry 
positions  are  recalculated  each  time  an  entry  is  changed.  As 
this  can  significantly  slow  down  the  model  when  larae  grids 
and/or  complicated  numerical  expressions  are  used,  the  user 
can  enter  "manual"  recalculation  mode  where  a  command  ^ust 
be  issued  to  cause  recalculation  to  occur. 

VISICALC  orovldes  a  command-line  oriented  editor  that 
enters,  modifies,  or  deletes  data  in  a  referenced  entry 
oositionCs).  A  cursor  is  crovided  on  the  grid  to  indicate 
the  current  entry  position  referenced  ty  VISICALC.  There 
are  screen  commands  to  allow  the  user  to  scroll  across  tne 
grid  or  to  move  to  an  exact  Crow,  column)  entry  position. 
If  needed,  the  numeric  processing  capability  of  VISICALC  can 
be  us«»d  like  a  calculator  to  sucport  the  user's 
computational  needs.  A  powerful  capability  of  VISICALC  is 
the  reolicate  command.  This  allows  the  user  to  define  an 
entry  once,  and  then  have  it  entered  in  a  r  a  n  a  e  of 
successive  column  or  row  entry  Dositions.  Additionally,  the 
user  can  specify  if  the  original  entry  is  to  be  replicated 
exactly,   or   should  any  references  to  other  entry  positions 
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be  updated   at   each   new   position   to   ta*e   into   account 
relative  position  on  the  spreadsheet. 


Table  G.2  -  VISICALC  Cursor  Movement  &  Entry  Commands 


11.  Move  Cursor  Right  Or  Up 

12.  Move  Cursor  Left  Or  Down 

13.  Chanqe  Cursor  Direction; 

-  Up/Down 

-  Picnt/Left 

14.  .Move  Cursor  To  The  other  -vindow 

15.  Move  Cursor  To  A  Specific  Entrv  Position. 

16.  Abort  Last  Command 

17.  Set  An  Entry  Position  To  Blank 

18.  Delete  An  Entire  Row  Or  Column 

19.  Inset  A  Mew  Row  Or  Column 

20.  Replicate  An  Entry 

21.  Set  Title  Areas; 

-  Horizontal  Title 

-  Vertical  Title 

-  No  Title 

22.  Reoeat  A  Label  Entry 

23.  K'axe  An  Immediate  Numerical  Calculation 

24.  Enter  A  Label  In  An  Entry  Position 

25.  Enter  A  Value  In  An  Entry  Position 
2^.  5a\fB    A  Codv  Of  The  Soread-Sneet 


Since  VISICALC  is  a  numerical  modeling  tool  it  has  a 
series  of  arithmetic  and  aaoregate  functions  that  it 
supports.  Table  G.2  orovides  a  listing.  VISICALC  has  been 
designed  to  store  numbers  in  decimal  format,  not  binarv,  and 
maintains  them  with  uo  to  eleven  significant  diaits  or 
decimal  Dlaces. 
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Table  G.3  -  VISICALC  Arithmetic  &  Aggregate  Functions 


a. 

o. 
c. 
d. 
e, 
f. 
9« 
h. 
1, 
J. 
k. 

1. 
-. 
n. 
o. 
o. 
d. 
r. 
s. 


Addi 
Sudt 
Mult 
Dlvl 
Expo 
Calc 
Calc 
Caic 
Coun 
Calc 
Calc 
Ra 
Pert 
PI  ( 
Calc 
Calc 
Saua 
Loga 
Loga 
Trig 

4C 


tion 
ract 
ipli 

sion 

nent 

ulat 

ulat 

ulat 

t  Th 

ulat 

ulat 

noe 

orm 

3.14 

ulat 

ulat 

re  R 

ritn 

rltn 

onom 

OS  , 


ion 
cation 

iation 

e  The  Sum  Of  A  Range  Of  Values 

e  The  Minimum  In  A  Ranoe  Of  Values 

e  The  Maximum  In  A  Range  Of  Values 

e  Number  Of  Entries  In  A  List 

e  The  Average  Of  A  Ranae  Of  values 

e  The  Net-Fresent-Value  Of  A 

Of  Values 

A  Lookup  Operation 

15926536) 

e  The  Absolute  value 

e  The  Integer  Portion 

oot 

ms,  Base  2 

ms,  Base  10 

etric  Functions  (Sin, 

Atan) 


Of  A  Value 


Cos,  Tan,  Asln, 


VISICALC  makes  use  of  dynamic  memory  allocation  so  the 
actual  dimensions  of  the  spread-sneet  depend  on  the  amount 
of  memory  available  and  tne  complexity  of  the  entries  made 
by  the  user.  The  user  does  not  have  to  worry  about  memory 
allocation  since  VISICALC  takes  responsibility  for  its  use 
and  efficiency.  As  entries  shrink,  or  are  deleted,  VISICALC 
reclaims  the  extra  memory  space.  The  user  is  shown  now  much 
memory  remains  and  a  warning  prompt  occurs  when  memory  space 
is  nearly  exhausted. 
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For  a  permanent  copy  of  the  contents  of  the  spread  sheet 
the  user  may  send  the  output  to  a  printer,  A  suDpart  of  the 
total  spread-sheet  may  be  sent  by  designating  the  lower 
right  corner  to  be  printed, 

VISICALC  is  a  powerful  and  fairly  simple  modeling  tool 
whose  advantages  seem  to  easily  outweigh  the  disadvantages. 
The  command  vocabulary  is  low  (26  commands,  19  functions) 
and  the  greater  majority  are  actually  useful  and  not  just 
window  dressing.  The  user  manual  is  well  written  and  easily 
understood,  but  is  fairly  long,  VISICALC  supports  a  Known 
human  weakness  Csmall/fast  short  term  memory,  large/slow 
long  term  memory,  and  slow  calculation  speed)  by  remembering 
the  details  of  a  commonly  reoccurring  user  oroclem  (the 
situation  to  be  modeled),  limitinq  the  user  to  Dr'oviaino  a 
smaller  and  more  select  set  of  initial  Incuts,  ana 
performina  the  computations  in  a  faster,  more  reliable,  and 
reoeatable  manner.   However  it  does  have  some  proDlems: 

(1)  Command  strings  and  their  effect  must  be  memorized 
since  there  is  little  relation,  to  the  strina  and  the  effect. 
Menus  provided  by  the  system  are  very  poor,  and  require  you 
to  already  Know  the  meaning  of  tne  command  string, 

C2)  A  basic  understanding  of  VISICALC  and  a  high  deqree 
of  operational  capability  can  be  obtained,  in  a  fairly  short 
time,  by  reading  only  the  first  third  of  the  user  manual. 
However,   to   gain   maximum   use   of   the   system  requires  a 


119 


significant  amount  of  time  and  effort  to  read  the  entire 
user  manual  and  experiment  with  the  operations.  Some  nice  to 
Know  features  that  have  a  major  effect  on  model  validity 
(e.g.  recalculation  order)  are  discussed  at  the  end  of  the 
user  manual  and  might  be  easily  missed. 
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APPENDIX  H:  ZIP 

The  relational  data  base  management  systerr  "DBASE  II", 
described  In  Appendix  CD),  contains  a  set  of  commands  which, 
when  embedded  in  a  "command"  file,  define  the  output  format 
used  to  generate  the  display  on  the  screen,  or  outDut  to  the 
printer.  In  addition  to  generating  the  display  form,  the 
commands  also  direct  the  DBASE  II  system  to  either  determine 
the  values  of  the  entries  from  a  record  in  the  referenced 
database,  or  from  memory  variables.  If  the  inout  device  is 
the  screen/keyboard,  D3ASE  II  may  retrieve  a  user  entered 
value  from  tne  screen  and  store  it  in  a  field  of  a  dataoase 
record,  or  in  a  memory  variable.  These  form  definition 
commands  can  also  be  out  into  a  new  tyoe  of  file,  the 
"format"  file,  by  ZIP.  In  this  case  the  format,  contained 
in  the  "format"  file,  is  used  as  an  display  overlay  to 
prompt  the  user  to  chanae  data  values  in  an  existing  record 
in  a  "database"  file. 

ZIP  is  a  CP/M  program  used  to  generate,  or  modify,  a 
DBASE  II  "command"  or  "format"  file.  It  is  a  oowerful  tool 
in  tne  sense  that  the  user  is  not  required  to  Know  the 
details  of  the  DBASE  II  form  generation  capability 
("command"  files,  and  display  commands).  ZIP  presents  the 
user  with  a  blank  screen  and  an  on-screen  editor,  wnicn 
supports  several  levels  of  cursor   movement   and   formatting 
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commands,   to   help  In  the  form  design.   Table  w.l  lists  the 
ZIP  editor  commands. 


Table  H,l  -  ZIP  Editor  Commands. 


1.  Screen  commands 

-  top 

-  bottom 

-  next 

-  previous 

-  first 

-  last 

2.  Middle  of  line 

3.  Insert  a  space 

4.  Add  a  line 

5.  Delete 

-  character 

-  line 

6.  Draw/Erase  horizontal  line 

7.  Draw/Erase  vertical  line 

8.  Erase/Save  work  file 

9.  Insert  DBASE  II  command  expression 

10.  Change  variable 

-  vertical  marker 

-  horizontal  marker 

-  tab  spacing 

-  margin 

-  cage  length 

11.  Quit 


The  cursor  can  be  moved  to  any  oosition  on  the  blank  screen 
where  the  user  will  enter  the  information  reauired  by  the 
ZIP  program.  Information  is  conveniently  limited  to  literal 
strings,  memory  variables,  record  field  values,  and  fetching 
a  value  from  the  screen  and  storing  it  into  a  record  field 
or    memory    variable,-    Interspersed    oetween   these   ZIP 
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formatting  commands  may  be  DBASE  II  executable  commands  if 
the  file  type  is  "command".  There  are  special  purpose 
commands  to  draw,  or  undraw,  vertical  and  horizontal  lines 
on  the  form. 

The  ZIP  program  may  be  viewed  as  a  translator  between 
the  screen  design  made  by  the  user  and  the  operations  of 
DBASE  II.  The  screen  contents  associated  with  each  screen 
position  are  translated  into  a  sequence  of  DBASE  II 
commands,  statements,  and  control  structures  which  are 
organized  as  either  a  "command"  or  "format"  file.  ZIP  also 
places  any  embedded  execution  commands  into  the  file  and 
automatically  sets,  or  resets,  tne  appropriate  system 
"toggles"  as  needed, 

ZIP  is  a  useful  suoport  tool  for  DBASE  II  in  that  it 
relieves  the  user  from  having  to  Drogram  a  "command"  file  in 
order  to  create  a  desired  display  format.  However,  it  *ust 
oe  pointed  out  that  ZIP  is  a  very  basic  formatter,  is  line 
oriented,  and  is  incaoable  of  the  more  comDlex  types  of 
displays. 
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APPENDIX  I:  MAIL- 

"MAIL"  is  an  electronic  mall  facility  produced  by  tne 
University  of  California  at  Berkeley  and  Bell  Laboratories 
for  the  UNIX  operating  system.  It  allows  users  to  send 
messaaes  to  otner  users,  or  groups  of  users,  on  the  system. 

The  basic  unit  of  tne  mail  system  is  tne  message,  which 
is  simoly  a  special  type  of  text  file.  The  messaoe  is 
Preformatted  and  contains  fields  for  originator, 
destination,  subject,  copy  to,  and  body.  Messages  are 
contained  either  in  the  users  "orivate"  mailbox  or  in  the 
"system"  mailbox.  A  "dead-letter"  file  is  also  maintained 
for  each  user  to  contain  messages  which  cannot  be  delivered 
to  a  valid  destination.  Tne  private  mailbox  and  dead-letter 
file  are  maintained  as  text  files  in  tne  UNIX  directory  and 
therefore  can  be  used  by  other  Droarams  running  under  UNIX. 

UDon  loggina  into  the  UNIX  system,  a  promct  apoears  at 
the  terminal  indicating  that  there  is  mail  for  the  user. 
Messages  addressed  to  a  user  are  initially  contained  in  the 
system  mailbox,  and  can  be  read  from  tne  system  mailbox  oy 
the  mail  facility.  The  messages  already  in  the  private 
mailbox  and/or  dead-letter  file  are  text  files  ana  tnus  not 
directly  accessible  to  the  mail  facility. 

The  user  may  elect  to  read  the  mail  by  invoking  tne  mail 
facility.    A  one  line  summary  of  all  messages  in  the  system 
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mailbox  Is  presented  to  the  user,  and  each  message  is   given 

an   integer   identification  number  starting  at  one.   At  this 

point  the  user  has  a  number  of  different   options   available 
as  summarized  in  Table  1.1. 


Table  1.1  -  MAIL  Command  Summary 


1. 
2. 

3. 

4. 
5. 
6. 

7. 
8. 
9. 

10. 
11. 
12. 
13. 
14. 
15. 
16. 
17. 
18. 
19. 
20, 
21. 
22. 


23. 
24. 

25, 

26. 
27. 
28. 


Alias 

Unali 

Goto 

Goto 

Displ 

DiSPl 

Displ 

Displ 
Displ 
DiSDl 
Displ 
Execu 
Chang 
Delet 
Delet 
Undel 
Reply 
Edit 
Send 
End-e 
Exit, 
Quit, 
use 
sys 
Marx 
Save 
List 
Help 
Set  o 
Unset 


a  n 
as  a 
prev 
next 
ay  s 
ay  o 
ay  a 
ay  o 
ay  m 
ay 
ay 
te 
e 


s 

t 

t 

di 


e  me 
e  cu 
ete 
to 
a  11 
mess 
f-me 
don 
sav 
r's 
tern 
mess 
a  me 
curr 
+ 

DtiO 
Opt 


ame  + 
name 
lous 

mess 
ummar 
ut  al 
mess 
ut  he 
essag 
ize  o 
op  f e 
he  fo 
recto 
ssage 
rrent 
messa 
a  rec 
st  of 
age  t 
ssage 
't  en 
e  und 
m  a  i  1  o 
mailb 
ageCs 
ssaae 
ent  r 

ns  -f 
ions 


Cs) 

mess 
age 
y  of 
1  cu 
age 
ader 
e  li 
f  ea 
w  li 
How 

ry 
cs) 

mes 
ges 
eive 

mes 
o  de 

♦• 
ange 
elet 
ox, 
ox. 
)  to 

lis 
ange 


age  ♦  ♦ 

♦  + 

commands  + 
rrently  defined  aliases 

s  of  message  list  * 
st 

ch  message 

nes  of  each  messace 

lng  UNIX  shell  command 

+ 

sace,  print  next  -nessaae 

marKed  for  deletion 

d  message  * 

sages  in  turn 

sionated  users  + 

system  mailbox  * 
eg  or  unsaved  messages  in  the 
save  unreferenced  in  the 

be  saved  in  system  mailbox  * 
t  by  appending  to  a  text  file 
of  message  neaders 


MAIL  facility  has  more  than  one  command  to 
perform  this  action. 
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The  user  may  select  a  message  and  read  It,  After 
reviewing  the  message  the  user  may  forget  the  message,  save 
it  in  the  system  mailbox,  delete  it,  or  prepare  a  resoonse. 
When  the  user  guits  the  MAIL  facility  all  messages  which 
have  not  been  deleted,  saved,  or  reviewed  are  placed  oac< 
into  the  system  mailbox.  The  remaining  messages,  those 
reviewed  but  no  special  action  indicated,  are  placed  In  the 
private  mailbox.  If  the  user  desires,  the  MAIL  facility  can 
be  exited  and  the  system  mailbox  left  unchanaed. 
Additionally  the  .  user  can  create  "alias"  names  tnat 
correspond  to  multiple  users,  ask  for  message  summaries, 
append  messages  to  files,  or  invoke  an  editor. 

The  MAIL  utility  does  not  contain  its  own  editor,  but 
depends  on  the  editorCs)  available  to  the  UNIX  system  and  on 
the  user  to  set  an  option  specifyinq  which  one  is  desired. 
When  the  user  indicates  that  a  message  is  to  re  created,  the 
editor  is  invoiced,  the  user  enters  the  text,  ana  when 
finished  issues  an  end-of -message  command  to  return  control 
to  the  mail  facility,  while  in  the  editor,  the  user  can 
issue  "escape"  commands  that  directly  effect  the  message 
processing,  A  listing  of  these  escape  commands  is  provided 
in  Table  1.2.  Contents  of  other  files  may  be  inserted  into 
the  messaoe,  names  of  recipients  added  or  chanaed,  the 
header  field  edited,  or  an  alternate  editor  invoked. 
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Table  1,2  -  MAIL  escape  commands 


1.  Execute  UNIX  shell  command 

2.  Add  names  to  recipients  of  copy 

3.  Read  "deadletter"  file  into  message 

4.  Invoke  text  editor 

5.  ADort  the  message  being  sent 

6.  Insert  a  named  file  into  the  message 

7.  Create  a  subject  field 

8.  Write  tne  message  into  a 

9.  Pipe  the  message  through 

10.  Insert  a  string  into  the 


named  file 
a  process  as 
message 


a  filter 


While  in  the  MAIL  facility,  UNIX  shell  commands  may  be 
issued.  The  MAIL  facility  is  temporarily  interrupted,  the 
command  is  executed,  and  then  the  MAIL  facility  is  resumed 
without  adverse  effect. 


Table  1,3  -  *AIL  options. 


1.  (Append/Prepended)  messages  to  private  mailbox 

2.  (Yes/No)  Subject  line  prompt 

3.  (Yes/No)  Prompt  for  carbon  copy  recipients  of  message 

4.  (Yes/No)  Modify  delete  command 

5.  (Yes/No)  ignore  terminal  interrupt  signals 

6.  (Yes/No)  Include  sender  in  group  message  recipients 

7.  (Yes/Mo)  Saving  interrupted  messages 
fi.  nefine  default  editor  name 

9,  Define  escape  character 

10,  Define  file  to  record  outgoing  mail 

11,  Define  number  of  lines  in  the  "too"  of  a  messaae 


127 


Additionally,  the  MAIL  facility  has  a  series  of  options 
the  user  can  change  to  tailor  its  operation.  Table  1.3 
provides  a  listing  of  these  options. 

The  MAIL  facility  is  a  good  support  program  and  is  quite 
capable  of  accomplishing  its  goals.  However,  it  has  more 
than  its  fair  share  of  problems. 

CD  There  is  a  very  limited  user  manual,  and  experience 
must  be  gained  from  other  users  or  by  trial  and  error. 

(2)  There  are  too  many  commands,  and  too  many  of  those 
duplicate  each  other.  The  number  of  commonly  useful 
commands  is  low  (marked  with  a  +),  with  the  rest  being 
window-dressing. 

(3)  The  facility  is  not  user  friendly.  The  user  must  oe 
aware  of  location  in  the  facility  and  what  is  exoected  next, 
because  there  are  no  special  prompts  and  the  help  command 
only  provides  a  command  summary. 

(4)  If  the  message  recipient  is  on  line  when  the  message 
arrives,  whatever  operation  is  in  progress  is  rudely 
interrupted  oy  the  display  of  the  message.  This  can  be  very 
disconcerting  to  the  reciDient. 

(5)  The  user  can't  determine  which  message  is  goina 
where  Csvstem  mailbox,  Drivate  mailbox,  dead-letter  file), 
prior  to  leaving  the  mail  facility. 
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